interfaces, object paths and activation

[Mark McLoughlin]

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);
      };

    So, that might not seem important, but what it means is that
    there is no canonical description of an interface - i.e.
    saying that an object implements the org.freedesktop.DBus
    interface is meaningless.

    The only really important information about an object is the
    methods an object implements, not the interfaces it instantiates.

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

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

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

    This sounds kind of similar to distinction in CORBA between
    persistent and transient object references. Persistent references
    would have well known object paths, whereas transient ones use
    opaque (to the client) object ids.

  + 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 ?

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

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

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

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

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

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

  + It would be nice to be able to bootstrap to a session bus without
    knowing its address. That's always mildly annoyed me about X and
    XSMP (you need to figure out $DISPLAY or $SESSION_MANAGER). Perhaps
    you should be able to bootstrap to the system message bus using
    the well known location and ask the system bus for a list of
    available session buses?


	(Pardon me, I'm really beginning to ramble)

	
	Some small, specific issues from reading the spec:

  + Four character header field names are already pretty obtuse and
    annoying. I don't why its so important for these to be human
    readable when the rest of the header isn't. Why not just make
    this a UINT32 and give them each a "Conventional Name" too which
    you would use to refer to it throughout the rest of the spec?

  + Why make the 'ifce' header field optional? I don't see why we want
    to leave the way open for that ambiguity. You may find a client
    relying on it, and next thing you realise the service cannot
    implement some other interface with the same method name because
    there are deployed clients which would break.

  + Signal emissions require the interface which seems strange if
    methods don't require it.

  + In the method definition notation, I think it would be a lot better
    to allow the user of a return values rather than an "out" parameter.
    Its going to make things a lot more readable.


Cheers,
Mark.