Detachable libpurple - RPC system

gillou.ray at gillou.ray at
Sun Jun 6 01:06:24 EDT 2010


I'm currently working on the detachable libpurple session project
(google summer of code) [0]. 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
   properly handled.
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

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 [1], 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 [2]. 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?


		-- Gilles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <>

More information about the Devel mailing list