Object path values - which service do they belong to?

[Havoc Pennington]

On Tue, 2005-05-17 at 13:27 -0400, Colin Walters wrote:
> 
> What I'm doing in the GLib bindings now is mapping it on the client end
> to DBUS_TYPE_G_PROXY, and on the server end mapping it to G_TYPE_OBJECT.
> This feels pretty natural I think, but it is based on the assumption
> that an object path always refers to an object on the same service as
> the method.

I feel like you might be making the glib bindings too "thick," but I
haven't looked at the details enough to convert that into a constructive
comment about where I would put the balance... it's just a vague
feeling.

Maybe: if we're going to have this API, why wouldn't we make things just
work? We can easily have a data type that includes an ID for the service
and whatnot. I think in the past we discussed an "IOR" (in CORBA terms)
(which would be an address, a bus name (if the address is for a bus),
and then an object path. An "object reference" type would encode this
info essentially but perhaps in more efficient form. The purpose of that
GUID thing I added is to provide a way to identify a server in order to
scope bus names and object paths.

The concept with "object paths" was to choose transparency of how it
works, as in dcop or xml-rpc, rather than a leaky abstraction that makes
objects look like local objects. Calling the object a "proxy" and
encouraging multiple proxies per remote object is intentional to beat
people over the head with this.

Another angle is that "location transparent" is a feature that was
punted from D-BUS on purpose. If we want it back, we should go back and
engineer it in cleanly; we shouldn't creep it back slowly in a
poorly-designed way.

I don't think what I've written above is really right, but it gets at a
feeling I have.

Havoc