feat(jsonrpc): require Sync on transport params

[clint419]

No description provided.

[xJonathanLEI]

Can you explain how adding more constraints is improving flexibility? Also please don't submit PR without any description unless it's something very obvious like typo fixing. Thanks.

[clint419]

Can you explain how adding more constraints is improving flexibility? Also please don't submit PR without any description unless it's something very obvious like typo fixing. Thanks.

Sorry, Purpose Used to customize JsonRpcTransport for extend, you can see ethers-rs, Thanks

[xJonathanLEI]

I guess I wasn't clear enough. I was asking for a specific example of what use case this enables. Like what scenario is this change enabling? What wasn't possible before this change and made possible thanks to the proposed changes?

[clint419]

Hi~, @xJonathanLEI

I have added a transport for read and write separation(RwTransport), you can have a look at my sample, and later, according to more usage scenarios of our company, add more transport, such as RetryTransport, FailoverTransport and so on. Thanks.

[clint419]

@xJonathanLEI
Hi~, I have added for RwTransport and FailoverTransport, you can look at the commit code. Thanks

[clint419]

I guess I wasn't clear enough. I was asking for a specific example of what use case this enables. Like what scenario is this change enabling? What wasn't possible before this change and made possible thanks to the proposed changes?

Add constraints, you can implement more Transport, otherwise, the library user can not customize. usage scenario, such as read/write separation, fault tolerance and so on.

[xJonathanLEI]

@clint419 Thanks for the update. I've reviewed the use case and agree that having Sync on P would be great as otherwise types built on JsonRpcTransport might need to unnecessarily clone it.

I've updated the PR to only include the changes on the trait though. The additional transport impls have been removed. It's possible to implement those outside of the library.

[xJonathanLEI]

This is a breaking change, but we're about to release a new version with many other breaking changes anyways. So we're good. Also this mostly only breaks applications that implement custom transports, and it's trivial to patch.

[xJonathanLEI]

LGTM