Object path values - which service do they belong to?

[Colin Walters]

On Wed, 2005-05-18 at 11:20 -0400, Havoc Pennington wrote:

> 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.

Thick in this particular case (DBUS_TYPE_OBJECT_PATH)?  Or in general?

> Maybe: if we're going to have this API, why wouldn't we make things just
> work? 

I wonder how often people will actually be passing around
non-service-local object paths.  So far I can't think offhand of a D-BUS
service I know of doing it.

> 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.

Ok.  That sounds pretty useful if people do want to pass inter-service
objects.

> 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 agree with that; I don't think mapping DBUS_TYPE_OBJECT_PATH to
DBUS_TYPE_G_PROXY is an attempt to make things "location transparent" or
anything so grand; it just makes the (so far) common case nice and saves
you the trouble of constructing the proxy yourself when you want to
actually invoke methods on the objects you get back.   

This was one of the initial comments David had about the glib bindings a
while ago; it's a pretty common pattern in HAL-using code (and
NetworkManager I think) to get an array of object paths and want to
invoke a method on each of them.  Not having to manually construct a
proxy for each of those is a bit nicer.

However, one thing I should note is that due to the way the bindings are
fully GType-based now, is that we can actually let clients choose how
they want object paths demarshalled, by passing different GTypes in.  It
would be pretty trivial to define a new DBUS_TYPE_G_OBJECT_PATH which
derived from G_TYPE_BOXED, and then we could use it like this:

GError *error = NULL;
char *objpath;
DBusGProxy *newproxy;

dbus_g_proxy_invoke (proxy, "GetObject", &error, DBUS_TYPE_G_OBJECT_PATH, &objpath, G_TYPE_INVALID, G_TYPE_INVALID);


newproxy = g_proxy_new_... (...objpath...);

i.e. basically treat it as a string.  And if they want to construct
proxies, they can use DBUS_TYPE_G_PROXY instead.

On the server side you don't get to choose, but so far I don't think
I've seen anyone passing object paths as input values, only return
values.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050518/34af62cc/attachment.pgp