Interfaces, Errors, and Python bindings (oh my)

[Havoc Pennington]

On Thu, 2003-09-25 at 06:04, Seth Nickell wrote:
> 
> 1) I think intuitively what we are calling "interfaces" are mostly just
> 2) Why? I was confused out of my mind by having three apparently similar

Right now the way it works requires the several namespaces. Remember
there is a no-bus mode where there are no services. But with the bus,
the service gets you to the right process, the object name gets you to
the right object, and the interface name gets you to the right part of
the object.

Possible simplifications:

 - rather than separate services, the bus pushes a prefix onto the  
   path. So each app connected to the bus can own paths in the 
   object tree of the bus, and the paths of the app are appended.

   While this simplifies the programmer view a little bit, it 
   complicates some other things, like tracking service lifetimes, the 
   security policies, and the implementation. It would probably mean 
   adding a fair bit more API/code to DBusConnection to support it as 
   well.

 - you can omit the interface names in the client API. currently 
   DBusGProxy requires them to be specified, but I expect the Qt 
   bindings won't.

 - we could let you register objects as the default handler 
   for messages to a given service name, then not require a path
   on the client side. Not sure this simplifies; it means you need a
   path sometimes but not other times. Also it means it matters 
   which service name you use to refer to the process. Right now 
   processes are expected to own a number of services but it doesn't 
   matter which one you send messages to. In particular 
   dbus_gproxy_new_for_service_owner() relies on "binding" to the 
   unique service name rather than the well-known name.

 - as you suggest you could simply have one big object in each app, 
   but this means you have to coordinate all libraries/modules doing 
   IPC in the process, and it means you can't have dynamic objects. 
   Also it doesn't map to DCOP.

 - we could somehow either on client or server side default the 
   interface name to the same as the service name if not specified, 
   though maybe too magic so just adds confusion

 - make paths into object references, i.e. don't use well-known object 
   reference names, just a string like "23425142" - but doesn't map to  
   DCOP and adds a lot of round trips, also adds more memory bloat due 
   to need to register all objects. (I implemented this on 
   dbus-object-names at one point, using a 64-bit int for the object 
   ref)

The three namespaces are often similar, but there are also cases where
they aren't:

 service = org.gnome.GnomeSession
 interface = org.freedesktop.Introspectable
 path = /org/gnome/desktop/Accessible
 method = Introspect

Or whatever. Anyway, it's a bit strange but I don't have a clever plan
for changing it. If you omit the interface on the client side it's
identical to DCOP except for the "org.freedesktop." or whatever in the
service name, which is just a convention (though one I think we should
follow, namespaces are a fact of life).

Havoc