interfaces, object paths and activation

[Havoc Pennington]

On Wed, 2003-09-17 at 11:09, Mark McLoughlin wrote:
> Hey,
> 	So, I've just taken a look at the dbus-object-names branch (well I've
> only closely looked at the spec) and I have various queries:
> 
>   + What is an "interface" ? Just a group of methods, right ?
>     AFAICS, we're not encouraging the definition of "interfaces",
>     just methods. e.g. we define:
> 
>       org.freedesktop.DBus.Hello()
>       org.freedesktop.DBus.ListSerivces(out STRING_ARRAY)[1]
> 
>     (Yes, this isn't what's specified in the document, but it should
>      be according to the described notation. Prolly just an oversight.)
>     
>     rather than:
> 
>       interface org.freedesktop.DBus {
>         Hello();
> 
>         ListServices(out STRING_ARRAY);
>       };
> 

You certainly _could_ specify this, and most likely that's what we
should do in the conventional notation. I didn't change the part of the
spec that defines the message bus methods yet I don't think.

>     Really, I'm just not seeing what this "interface" concept for
>     DBUS is trying to achieve.

Essentially what it achieves at the moment is namespacing the method
names. That is, if you have two GetFoo() methods from different base
classes you could disambiguate them.

But also you could do a layer that used queryInterface() type of
features. e.g. if we have interface org.freedesktop.DBus we could freeze
that, and later add org.freedesktop.DBusOptionalInterface, and you could
check whether the bus supported said interface.

It's true that it isn't enforced that if you claim a particular
interface you actually have all the methods in it, but that really can't
be enforced on the protocol level, only on the
how-you-implement-the-server API level.

We have XML "type libraries" (returned by the Introspect() call) and
those could be installed as canonical definitions of an interface to be
used by any APIs that wanted to add enforcement. This belongs on the
GLib/Qt wrapper level rather than libdbus level I believe.

>   + Object paths are only unique within an application, right? So
>     they don't fully address an object unless accompanied by a
>     server address (be that server a bus or an application). And
>     if the server address is that of a bus, it needs to be accompanied
>     by a service name.

That's right.

>   + When an object isn't identified by a well known path, you
>     make the object path basically just an opaque object id? In
>     that case it might be good to do the 64-bit array index
>     object id you were talking about.

The idea is that you can do dynamic IDs in any way that makes sense for
your application; e.g. you could do spreadsheet/cells/45/89 if you
wanted, or you could do myids/0x35abcd

In the GLib wrapper we could add a convenience way to do this for
GObject, something like dbus_g_object_register_dynamic () that didn't
take a path name; it would then create /org/gtk/dynamic/0xabcd or
something like that and implement it with the array lookup.

>   + What is the result of a service activation ? An application 
>     becomes the owner of that service, right ? Are multiple activations
>     of the same service allowed ? i.e. can an activation result in
>     an application becoming a secondary owner, or are just new primary
>     owners activated ?

Activation only involves the primary owner. Right now activation only
covers starting a well-known service by name. So they are all singleton.

This clearly needs extending in some ways, though it's possible to do
some of the extension external to the message bus; e.g. you could have
the well-known service MyFooBarFactory and then its job would be to
start up dynamically-named services.

>     (I'm not convinced by this whole secondary owner thing, btw :-)

Me neither (in fact activation as a whole is barely in the spec since I
think it needs a lot more thought - as do several aspects of the bus). 

The basic idea of secondary owner is that if I start 5 copies of GEdit,
one becomes "my editor" that documents open in; but if I then exit that
one, one of the other copies takes over.

>   + To invoke a method on a service, you need an object path as well
>     as the service name, correct? In that case, where do you get the
>     initial object path from? It seems like we're requiring people
>     to use well-known object paths on activated objects.

That's right. You have to start with a well-known path.

You may call a method that returns a dynamic path, though. Then you
could use the dynamic path to address non-well-known object.

>   + There is no querying for activatable services. I would imagine
>     you should need to be able to query on the methods (or 
>     "interfaces") which the service implements along with application
>     specific service properties.

Yes, see above (about MyFooBarFactory and general non-completeness of
activation).

We should look at KTrader and DCOP here in addition to Bonobo.

>   + Some generic "Name", "Description" and "Icon" properties would
>     be useful in .service files for service browsing. And a way to
>     query them, of course.

Right, part of the overall activation design that needs to be done.

>   + Why the $DBUS_ACTIVATION_BUS_TYPE environmental variable? Do we
>     have a real use case for it?

There was some reason we added it - grep for usage of it and you may
see, or I may remember. ;-)

>   + There is no way to define the required context for the activation.
>     E.g. you'll want to activate a different help service depending
>     on the LANG of the activation client. Not as bit an issue as it
>     was with bonobo-activation, since we'll be using a per-session bus
>     rather than the per-user bonobo-activation daemon.

If you're starting a well-known singleton service, it's broken to have
that service change depending on who activated it. So at the moment it's
somewhat irrelevant.

Once you can activate dynamic multi-instance services, agreed.

(Or in this example perhaps it's org.freedesktop.HelpBrowser.en_US as
the service name?)

Hmm, have to go, will answer the rest of your mail later. ;-)

Havoc