[Twisted-Python] RPC design questions
tobias.oberstein at tavendo.de
Mon Aug 22 17:09:00 EDT 2011
I'm currently making some light-weight RPC/PubSub over WebSockets
I have two design-like questions where I'd be happy for advice/options ...
The first is definitely Twisted related, the second not strictly, ..
I'd like to chain RPC calls, i.e.
self.call(23, "square").addCallback(self.call, "sqrt").addCallback(self.show)
self.call(<arg>, <procedure>) will return a deferred, <arg> is the marshalled argument
for the RPC, and <procedure> is the remote procedure identifier.
Now, the nice thing is, I can chain the result from one call to the next like in the
What I find less nice is that I have to have that order : <arg>, <procedure>
since the result of the first deferred will be passed as the first argument to
the second, and only then will the additional arguments be passed (in above
example the "sqrt")
How can I retain the - which I find - natural order for arguments?
self.call("square", 6).addCallback(self.call, "sqrt").addCallback(self.show)
=> not working, the 2nd self.call receives 36, "sqrt" ..
The server side methods a hooked up using decorators, like
def square(self, arg):
return arg * arg
Here, AutobahnServerProtocol derives (indirectly) from Twisted Protocol.
The decorator will register the method for RPC under "square".
That is all nice and simple, however I am wondering if it's a good idea to
do that auto-registering on a Protocol derived class.
I mean, the alternative could be having the user call something like
registerRpcObject(<any class instance with RPC decorators>, <base URI>)
in Protocol.connectionMade(), which then would auto-register all decorated
methods in <any class instance ..>
What do you think would be better?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python