D-BUS for Network RPC

[Sean Middleditch]

On Wed, 2005-01-19 at 14:36 -0500, Stephen J. Scheck wrote:
> One problem with HTTP is that what I'll call "session persistence"
> semantics are not well defined/supported by the protocol, and it
> becomes an implementation issue. To support an RPC call, probably the
> XML protocols do an HTTP POST with the method arguments in the POST
> body, and the return values in the HTTP response. But what happens when
> you want to make several method calls on the same remote object? If
> these XML protocols are using a CGI handler to route the calls, the HTTP
> server will fork a process to handle the request which dies after the
> CGI script terminates, along with your object and its state. You can

That's an implementation issue.  If you don't like those semantics then
simply don't use a CGI script.  Nothing stops you from writing a custom
simple HTTP server (no different than writing any other kind of network
server) and use HTTP persistent connections.

> Actually, while we're on the topic, how does D-BUS handle "object"
> persistence? Since the spec mentions that connections are meant to
> be held open, I just assumed that I wouldn't run into the HTTP
> issue.

It doesn't matter much since its an implementation issue.  I could
easily write a D-BUS service that did indeed keep its connection to the
bus but forked off some other executable every time it received a
message.  D-BUS has absolutely nothing to do with object persistence or
application implementation - it's really nothing different than XML-
RPC/HTTP except with the whole bus bit added in - the only really
important difference is that D-BUS support bi-directional messages
where-as XML-RPC does not.

That said, the lack of a tested and secure D-BUS transport for TCP isn't
really a problem - just contribute one.  ;-)