interfaces, object paths and activation

[Havoc Pennington]

Hi,

btw, we do need to start planning/discussing object activation in a
serious way, it's approximately the right time to do so I think, libdbus
is getting close to its final form I hope. If I were doing it I'd start
by listing use cases in GNOME/KDE and looking at current Bonobo/DCOP
systems.

Signal connections are the main thing I would still like to iron out
before moving dbus-object-names back to HEAD.

Anyhow, some brief replies to your other queries:

On Wed, 2003-09-17 at 11:09, Mark McLoughlin wrote:
>   + 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?

The system bus does support a well-known location, determined at compile
time (though it really should be determined from a config file at
runtime, since you can change the location the system bus listens in the
config file at runtime).

If session buses registered with the system bus, I guess the issue is
how do you know which one you should connect to? i.e. if we have a map
from sessions to session bus, what is the key (identifier for a
session)?

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

Yeah, just having an enum would probably work fine. I buy that. 

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

The basic reason it's optional is that DCOP doesn't have the interface
concept (well, it has an introspection method interfaces() but otherwise
there's no interface concept on the DCOP level).

So the KDE APIs don't make developers pass in the interface name right
now. I think it's cleaner if the introspection "typelib" XML is returned
with interfaces, and machine-generated code using that uses the
interface names, and humans can optionally use them. In fact with the
GLib bindings we may always use them. Having the concept also helps us
map to CORBA if we want to bridge D-BUS and CORBA in some way. 

But I don't want to make the DCOP-like API backended off of D-BUS look
more complicated/harder than it currently does.

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

The rationale is that you always know the interface when you're emitting
(for example in the KDE APIs we can automatically come up with the
interface from the QObject, at least I think we can).

While when invoking a method call, the only way the interface is known
is if the client programmer types it in to the code.

You also need the interface to implement Introspect(), so generally
speaking the server knows the interface names and the client doesn't
necessarily.

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

Yeah. The thing is that right now the protocol makes no distinction
between C functions like these two:

 int frobate   (char *arg1);
 void frobate (char *arg1, int *arg2);

any distinction there is purely an API or "language binding" issue.

We could create the distinction (probably as part of moving the type
signature to a single place, rather than putting the type in front of
each arg).

However, I think it's a little bit bogus to have the distinction in the
protocol, as it's really nothing but syntax.

Obviously to have two return values in C/C++, you have to move to the
"out params" form.

If there's no distinction in the protocol, I feel like it might be
misleading to use return values separate from out params in the spec.

Havoc