D-BUS for Network RPC

[Daniel P. Berrange]

On Wed, Jan 19, 2005 at 11:53:12AM -0500, Havoc Pennington wrote:
> On Wed, 2005-01-19 at 10:42 -0500, Stephen J. Scheck wrote:
> > - How does the design and architecture of D-BUS make it optimized for 
> >   local use, and thus would make it unsuitable/inefficient for network 
> >   RPC? Is there any reason why it wouldn't make a good candidate for
> >   simple and light-weight network RPC applications?
> 
> It probably works OK, it just hasn't been designed or thought about in
> that context.

While it may not be specifically designed with networked use in mind, one 
can easily envisage scenarios where it'll be important for DBus to operate
well across networked machines - not arbitrarily connected across the 
Internet - but certainly in a LAN environment & probably corporate WANs
too.

One such scenario is that of a development environment, where a pool of 
shared servers is available to developers. While a user would have a local 
machine for their desktop apps (browser, mail, etc), they might login to
one of the remote machines for development, perhaps running Eclipse & other
dev tools & apps remotely. So whether an application is local to the
developer's machine, or remote it'd still want to communicate through 
DBus. 

If one accepts that the use of DBus as a per-user desktop session bus
will neccessitate it working between applications spanning the LAN,
its not really much more of a technical leap for it to function well 
as a messaging bus for other networked systems. The security aspects
of authentication & authorization are probably the most important
things to consider for a networked enviroment. 

Going back to the scenario of an intranet development environment. I've
been giving some thought & doing experimentation with DBus as a way of
connecting up development tools / services, to facilitate the flow of
information from tools to the developers. For example, a GNOME panel
applet to provide live progress monitoring of Test-AutoBuild servers 
(via signals emitted after each package builds) to replace current method
of polling of an RSS feed (which is only updated at end of a build cycle). 
At the other end of the pipe, perhaps an Eclipse plugin to use DBus as 
the transport to make a method call to the build server to schedule a 
package on the next build cycle.

While statless protocols like XMLRPC / SOAP / HTTP REST would be fine 
for the method call/return needs, these protocols aren't too great for 
live monitoring which really benefit from being stateful. Jabber would 
be good for the pub/sub notification aspects, but for the formal RPC calls
you'd need to have another layer on the basic protocol. Then CORBA, while 
unquestionably adaptable, has a level of complexity & overhead that I 
like to avoid. DBus seems to slot very nicely into the middle ground 
between all these systems & the availability of easy to use bindings for
all significant programming languages is great making it easy to integrate 
with a huge range of applications / tools.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange@redhat.com  -  Daniel Berrange  -  dan@berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050119/0e49f4fe/attachment.pgp