More high-level tools

[hovi]

This library seems like solid foundation, to avoid too much boilerplate, I would like to do things like:

• Decorator that runs some method using try-except and then automatically wraps the results in Success or Error
• Decorator similar to @method that can be used on class that will then automatically add all class method to dispatcher (possibly with help of ABC module and @abstractmethod)

Basically what I have is interface that I want to be used over json-rpc and to create json-rpc client and server as simply as possible without much boilerplate code as there will be more interfaces like that.
Is this anything you see as useful in this library (and it's client part)?

I will also probably add other transport methods (so far I found in the code only "serve", which does simple HTTP). I may possibly add TCP or intergrate with django routing depending on what will we require for our use-cases.
Happy to make some PRs.

[bcb]

Hi @hovi , interesting suggestions, I'll respond to each:

1. Decorator that runs some method using try-except and then automatically wraps the results in Success or Error

If I'm understanding correctly, the library already works like that - it gives an Error response for any unhandled exception raised in the method.

2. Decorator similar to @method that can be used on class that will then automatically add all class method to dispatcher

There is a methods param passed to dispatch I think would help with this. Better to use a dict than using OOP in my opinion.

3. Add other transport methods

We've had transport frameworks in the past but removed them for reasons:

• It's limited to the few protocols/frameworks supported.
• It supports them with varying degrees of success, some very poorly.
• The user doesn't have control of how the transport works.
• Breaking changes to one of the frameworks requires a new version of the library. Managing the dependencies becomes a pain.

jsonrpcserver is just dispatch - that's it. It can be used with any framework and the user has control.

Having said that, there's no reason another library can't build on jsonrpcserver, using it as a dependency.

[hovi]

Thank you for great response. I like this conservative and "small and clean" approach so definitely understand your point of view.

1. Great, I missed that!
2. I have interface defined by abstract class. It seems very natural to use this abstraction to create json-rpc client proxy and then json-rpc server implementation without any kind of manual mapping (like creating this dictionary). My "dict" is already this class and @abstractmethod annotations. That is imho much nicer and cleaner definition of RPC. Creating this "dict" from my class and passing it to dispatch is quite simple so all good.
3. Understood, but some pointers on why I would like them:

• I think that the fact that the user doesn't have control of how the transport works is the whole point of RPC - you don't want to control or care, you just want to invoke methods.
• Can you point me to some of those implementations if they are still in the git history please?

If I create something useful mentioned above, I will link it from here :-)