[types] Remove unnecessary deps

[c410-f3r]

No description provided.

[niklasad1]

Thanks for your PR.

Looks overall good but I don't really understand the rationale behind making this crate no-std without the client traits then it's not super useful, such as the proc macros wouldn't work. I suppose making the SubscriptionClient trait std only (subscription type) and make Client trait no-std would do it.

Can you elaborate why making the types no-std is useful? The intention is that it's a internal crate for jsonrpsee but maybe useful for other purposes?

[c410-f3r]

no_std support is usually a complementary and natural step when removing unnecessary dependencies. Besides, isn't it something desirable in the long run?

If necessary, I can remove no_std stuff. No problem.

[niklasad1]

no_std support is usually a complementary and natural step when removing unnecessary dependencies. Besides, isn't it something desirable in the long run?

Sure, why not it introduces some boiler plate code for the error stuff but worth it if somebody wants to use the types in no-std but we have no plans making client/server to support for no-std however we have plans to move the HTTP client to use surf as backend for WASM support

[niklasad1]

LGTM except the typo, see inline suggestion.

[c410-f3r]

IIRC, WASM language isn't aware of std stuff (filesystem, threads, timer, etc) and that is one of the reasons for the creation of WASI.

[niklasad1]

IIRC, WASM language isn't aware of std stuff (filesystem, threads, timer, etc) and that is one of the reasons for the creation of WASI.

Yes, but it's possible to do it with JavaScript bindings too as surf/http-client does.

[c410-f3r]

Cool! Thanks for the link

[dvdplm]

Reducing compile times is great, thank you so much for looking into this.

I agree with @niklasad1 that no-std is not a goal and adds more noise than it's worth imo. I also think that the added boilerplate around errors is questionable. I prefer it the way it was.

Any chance we can keep the compile time improvements without the inlining, no-std, and error re-implementations?

[niklasad1]

@dvdplm please take another look at this PR ^^