Detachable libpurple - RPC system
gillou.ray at free.fr
gillou.ray at free.fr
Sun Jun 6 01:06:24 EDT 2010
I'm currently working on the detachable libpurple session project
(google summer of code) . An important part of this project is the
choice of the technology used to make the remote calls. I discovered
that there are many RPC standards and implementations. I identified some
criteria our system would have to idealy provide (sorted by importance,
1. C langage. This is obvious and not related to the standard, but
this excludes many existing libraries.
2. Licence compatible. GPL prefered.
3. Bidirectional communication. The client will make remote calls
and the daemon will send events to the client.
4. Cross-platform. Or at least to the 3 main platforms pidgin and
folks are known to run on.
5. Facilities to handle network problems. Disconnections must be
6. Authentication. We have to get at least a basic authentication
system so that not anybody can connect to the daemon.
7. Encryption. All the encryption used in IM communication would be
useless if the dameon/client data is sent clear. Though this part
may be provided by another library such as TLS or SSH.
Do you see anything left ?
Numbers 5, 6 and 7 aren't needed to basically make the thing to work.
Even if it wouldn't be available at the end of the summer, it has to be
thought for a possible future implementation. Number 3 is essential and
exclude many existing RPC systems, such as the Sun RPC system used by
NFS, XML-RPC or SOAP.
I red some docs and tutorial about DBus. It seems to be a good choice
as it provide # 1, 2, 3, 4 and 5. It's well designed and provides a
good abstraction. However, DBus isn't designed for TCP/IP remote
connections, though this transport is implemented. DBus authentication
is based on socket uid or magic cookies , this only makes sense in
the scope of a single machine. Currently we would have to avoid
authentication, or to implement another authentication method in DBus
and get it accepted by the DBus developpers. The same goes for the
encryption that relies to DBus and isn't implemented . So # 6 and 7
would remain unachieved.
I'm not very experienced in RPC, maybe there are others technologies
that would fit our needs? Do you think it's a good idea to make another
RPC system from scratch that would perfectly match our needs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Devel