incubator-tashi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stroucken <mxs+apa...@cmu.edu>
Subject RPCs vs other means of communicating with server
Date Wed, 22 Feb 2012 21:10:41 GMT
Hi,

Looking at the code as it is right now, where clients try to call 
functions by name on a remote server, I'd like to see whether we should 
keep rpyc or consider other client server protocol mechanisms.

rpyc upstream has dropped tlslite. With current version 3.2, we don't 
have a way to do username/password authentication anymore, because rpyc 
doesn't provide a way to provide custom authentication anymore before 
returning a handle to the server's RPCs.

With rpyc, the server implementation has to be tied to the client by way 
of function names, and parameter. Pain will happen whenever we need to 
add additional functionality to one of the RPCs.

My thoughts right now is that it may be advantageous to use python 
builtins to handle network communications, and to change the client 
server interaction to something resembling HTTP -- where lack of 
functionality can be gracefully handled and communicated back to the client.

We could still move serialized data around if we need to by something 
like a pickle|sign|base64 chain.

Please comment,
Michael.

Mime
View raw message