about signals

[Havoc Pennington]

Hi,

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.

Havoc