Crate restructuring

[maciejhirsz]

I need to start making smaller PRs. This one is pretty straight forward, removed the v2 module and moved things around to hopefully sensible locations.

Rationale: We added the v2 module when doing some internal refactoring that ultimately lead to different versions of types with similar names (Request most notably), but have since unified the apis to use same types, and with the "v1" absent there is no need for the module to exist.

Edit: see comment for ongoing changes.

[niklasad1]

👍

[dvdplm]

@maciejhirsz The PR description is a bit lacking here. Can you elaborate on why removing the v2 module is good? Not saying I disagree, but it is there for a reason (separate spec-mandated types from the rest) so it'd be good to write down why that reason is invalid/superseded.

[maciejhirsz]

@dvdplm Should be all tidy now + rationale, thoughts on having a linter for forcing braces on all the imports?

Edit: also @niklasad1 opinions here? :)

[niklasad1]

Rationale: We added the v2 module when doing some internal refactoring that ultimately lead to different versions of types with similar names (Request most notably), but have since unified the apis to use same types, and with the "v1" absent there is no need for the module to exist.

..., I thought we used v2 to indicate that these types are JSON-RPC v2 spec related types and not just common types after we removed the JSON-RPC spec related from the jsonrpc crate (way back). I like this change because it's a bit annoying to have to write jsonrpsee_types::v2::Response instead of jsonrpsee_types::Response...

thoughts on having a linter for forcing braces on all the imports

I don't like the braces for single imports if that's what you are suggesting but.... feel free to convince me :)
Then we need some special rustfmt rule...

[maciejhirsz]

..., I thought we used v2 to indicate that these types are JSON-RPC v2 spec related types (...)

We did? I thought it was just to keep stuff separate and it always bugged me. Given that 2.0 is the only version we support, and I don't think it's likely to change in the future I also don't see why we would need that differentiation.

I don't like the braces for single imports if that's what you are suggesting but.... feel free to convince me :)
Then we need some special rustfmt rule...

use foo::{a, b, c};
use foo::{d, e, f};

Or

use foo::{
    a, b, c,
    d, e, f,
};

(these names are short enough to fit in a single line, but you get the idea)

[niklasad1]

We did? I thought it was just to keep stuff separate and it always bugged me. Given that 2.0 is the only version we support, and I don't think it's likely to change in the future I also don't see why we would need that differentiation.

I think it was removed in https://github.com/paritytech/jsonrpsee/pull/269/files, maybe it's not needed but made it clear for which part of types that were just shared/common types in the repo and v2 - types that were strictly JSON-RPC specification related. However, I like it :)

(these names are short enough to fit in a single line, but you get the idea)

I don't care that much about that but I like 👇 better

use foo::{a, b, c};
use foo::{d, e, f};

[maciejhirsz]

I don't care that much about that but I like point_down better

Yeah, that's my preference too, I can revert some of the imports here.

[dvdplm]

We did? I thought it was just to keep stuff separate and it always bugged me. Given that 2.0 is the only version we support, and I don't think it's likely to change in the future I also don't see why we would need that differentiation.

It was never so much about versioning as it was about separating spec mandated types from the rest. The types from the spec must be kept intact forever while other public types can change with a breaking release. I think that is a worthy motivation for keeping things separate, and v2 seemed like a decent enough name for it.
However, given that wasn't clear to you @maciejhirsz I bet it isn't to many others, so we should perhaps consider a different name, maybe types::spec::StuffFromTheSpec?

[maciejhirsz]

The types from the spec must be kept intact forever while other public types can change with a breaking release.

I don't think that's true, we can easily make a breaking change to a spec type by changing stuff like String to Cow<'a, str>, or getting rid of the TwoPointZero type and just building a manual Serialize impl on request etc., without breaking spec compatibility.

[dvdplm]

I don't think that's true, we can easily make a breaking change to a spec type by changing stuff like String to Cow<'a, str>, or getting rid of the TwoPointZero type and just building a manual Serialize impl on request etc., without breaking spec compatibility.

You are correct, but you're missing the point: these types do require some extra care outside of the normal semver compatibility narrative. Question is: is this something that is worth signalling by keeping them in their own namespace? I think so, and that's what lies behind the v2 module.
I'm not opposed to rename the module and I'm willing to listen to arguments against keeping them separate from the rest but so far I remain unconvinced.

[dvdplm]

After discussion here's the plan:

1. Rename jsonrpsee_utils to jsonrpsee_core
2. Rename jsonrpsee_types::RpcError to jsonrpsee_types::ErrorResponse.
3. Move everything that's not a JSON-RCP transport type from jsonrpsee_types to jsonrpsee_core. This includes:
   3.1 Middleware and traits.
   3.2 Serialize, DeserializeOwned, beef::Cow, to_json_value, to_json_raw_value re-exports.
   3.3 All the error stuff that's not ErrorResponse, enums and other internal utils.

[dvdplm]

Clippy is angry about line 195

[niklasad1]

maybe we should re-export Deserialize here too..

[maciejhirsz]

Mayhaps, we are also super inconsistent about reexports, sometimes we put them in __reexports module, and sometimes not, I'd leave that for a future PR.

[niklasad1]

this crate is now what the v2 was?

[maciejhirsz]

Correct

[niklasad1]

LGTM, a few small questions....

This makes the repo structure more clear all good.

[TarikGul]

lgtm, It generally looks way cleaner to me (ie. the imports are way easier to follow).

The Macro export for rpc_params in core/src/client.rs took me a hot second to understand because github formatted it very weird, but overall 👍 from me.