hp at redhat.com
Fri May 28 12:06:56 PDT 2004
Just explained this all to Seth on the whiteboard (since he shared your
complaint) and convinced him the way it works makes sense ;-) but we
came up with some ideas:
1. potentially rename services to 'aliases' or 'connection names'
or 'addresses' or something like that
2. as you say, separate the base service from the well-known.
we could call the base service the 'connection id' and the
well-known services 'connection aliases' for example.
3. finish the bindings so "the way it's supposed to work"
is clear; the idea is that the binding APIs use the native
language concepts of object, interface, and signal.
e.g. you should not see the "sender" from the DBusMessage when
using a binding, instead you should see the proxy object and the
message args. And you can even call proxy.get_well_known_service()
if the proxy was bound to a well-known service.
4. maybe there should be a "default" object path if none is specified,
so each app conceptually has a giant global object instance that
can have a bunch of interfaces added to it - since if you're
exporting interfaces primarily to support a well-known service,
having to make up a path to a singleton object is pesky
5. actively discourage using the raw libdbus, as opposed to the
bindings, once the bindings are working. This may require a
"plain C binding" that makes up some crappy object/type system
and main loop... :-/ this should not be in mainline libdbus though.
More information about the dbus