D-BUS for Network RPC

[Stephen J. Scheck]

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
probably do object persistence with some kind of back-end SQL database,
but that is already way more complicated then I want to be. I'm sure
there are other strategies to deal with this problem, but 1) I'm not
familiar with them, 2) they seem like unnecessary complications and are
the result of making HTTP do something for which it wasn't designed, 3)
all of the solutions are non-standard and not defined in the protocol
spec, leading to interoperability issues, 4) I don't want to use Apache,
which is way too heavyweight for my purposes, and I'm not aware of other
HTTP servers specifically designed for this purpose (and which would
also support SSL/TLS).

At least, this is how it appears to me. Are there some *standards* for
XML RPC over HTTP which address these issues that I'm unaware of?

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.

Regards,

-sjs

On Wed, 2005-01-19 at 13:51, Waldo Bastian wrote:
> I would take a second look at XML-based RPC protocols, HTTP is quite simple 
> and you don't need a full fledged HTTP server in order to use it. It being 
> very popular probably also means that there is plenty of stuff out there 
> ready to use.
> 
> Cheers,
> Waldo