[patch] direct service connections

[Havoc Pennington]

On Sun, 2004-10-31 at 14:44 -0500, Colin Walters wrote:
> Attached is a simple patch which adds a new method,
> dbus_bus_connect_service_direct; this method returns a new
> DBusConnection.  The remote service has to implement a special
> org.freedesktop.DBus.Service method,
> org.freedesktop.DBus.Service.GetDirectConnection, that returns
> the address of the service.

An issue here is that you seem to imply semantics that a service[1] will
expose the same objects and interfaces on all connections. But that
isn't how it currently works; the object tree is per-connection. So you
can't get separate "direct connection" and "via bus connection" to the
same objects.

I think the elegant (but not necessarily right) approach here is to
imagine that libdbus or the binding library automatically manages
DBusConnection (file descriptors), and the app developer asks for
objects (DBusGProxy or equivalent) without specifying the connection.

One way this could work internally is that when you activate a service
on the bus, the bus could "redirect" (like http redirect) to an address
for direct connection. The app would then establish a new connection to
that address if it doesn't already have one, and instantiate the object
proxy.

There are a host of complexities, though. A simple one, an address isn't
a unique identifier for a remote process; we might need some sort of
guid made up by each process that's used to decide whether a new
DBusConnection has to be opened and potentially also to avoid a race
(redirecting process is replaced by another process at same address).

A harder one is that we probably have to split the object tree from the
connection objects. So e.g. signals would go out over all connections
using that object tree. Method calls would only go out over one
connection though. Exactly how all this works is pretty complicated.

Location independence is something DCOP has lived without, though I know
some people have been unhappy with that - IIRC said people were even
doing something similar to what you are, i.e. transferring image data.
D-BUS does add the *ability* to do a direct connection so is a bit
better than DCOP in that respect AFAIK, but D-BUS doesn't go as far as
CORBA and make it transparent.

Maybe a simple solution along the lines of yours would be to request a
direct redirect for *a specific object*, so something like:

 RequestRedirect ("/org/freedesktop/imsep/image_loader")

which would return an address *and* an object path to redirect to.

Another line of thought on this issue is how to make the current D-BUS
address into the equivalent of an IOR (object reference). The idea being
that you could pass around in string form the full instructions for
accessing an *object* (not just a process). That would then be the
natural return value for the above RequestRedirect.

If you then have a way to get DBusGProxy from an IOR without seeing a
DBusConnection object, then you have the location independence thing
working.

An IOR is probably an address, an optional service, and an object path.

Here's another line of questioning:
 - say imsep starts up and owns org.fd.Imsep on the bus
 - you contact org.fd.Imsep and it refers you to an alternate IOR
 - you thus connect to the Imsep process directly
 - the process loses the org.fd.Imsep service on the bus
   and is replaced by another process owning the service
 - what happens to the direct connection?

Havoc

[1] note here by service you mean process/application, not what dbus
actually calls a service - more evidence we really need to rename
"service", there was an old thread about what to name it. Maybe item #7
on the 1.0 list is rename stuff.