novehrady discussions

[Havoc Pennington]

Hi,

At Nove Hrady discussed dbus at some length with people there.  Some
of the changes that came up (other than already-planned stuff in TODO)
are as follows, currently I'm planning to make these changes.


I. Introduce object references in path format.
===

On the dbus-object-names branch I had the idea of an object ID as a
64-bit integer which encoded an index into an array. This is
low-bandwidth and also fast (you lookup an object by simply indexing
the array). However, it's not human-readable, requires round trips to
obtain the object reference (thus may be high-latency), and requires
registering each object with the dbus library.

The alternative, following DCOP, is to refer to objects with a path; 
for example, /abiword/menubar

Each object then has methods, e.g. /abiword/menubar/listItems(), 
/abiword/menubar/invokeItem() or whatever

Rather than keep a registry of all object IDs, the DBusConnection will
store a registry mapping root paths to message handlers. When a
message comes in that specifies a path, the message will be dispatched
to the registered handler for the root path that matches. So for
example on Qt initialization, Qt might register the /qt path, and then
route any path starting with /qt using the widget tree as in DCOP
today.

Typically, paths will be "well-known" (referring to persistent,
always-present objects). However, you can also create paths 
dynamically. For example you could have /abiword/documents/1, 
/abiword/documents/2, or something like that. Or simply
a unique string like "/dynamic/06980349"

You can think of paths as equivalent to monikers, except more
structured/limited (always in tree form), and that you don't resolve
the path then use the resulting object reference, you simply use the
object name as the object reference. This reduces latency.

The path mechanism also serves a similar purpose to the POA, 
in that it allows you to map remotely-visible objects to 
in-process objects in arbitrary ways (a real "object" need not exist
for every path, e.g. if you had /spreadsheet/sheet1/cells/4/rows/5
you need not actually have an object for every cell).

Diverging from DCOP a bit, I would like to suggest that paths are 
more tightly namespaced. something like:

 /com.trolltech/qt/foo
or 
 /org.abiword/foo

or perhaps even:

 /com/trolltech/qt

II. Object introspection via XML IDL
===

Each object implicitly has a method called something like
getTypeInfo(), which can be used to obtain an XML string. This XML
string is a document in to-be-determined format that describes the
methods, interfaces, and child "directories" at that point in the
object tree.  The XML would be generated dynamically by introspection.

The handler registered for the root path covering the path being 
introspected would handle the getTypeInfo(), so e.g. if 
Qt registered /qt it would use the QObject introspection features, 
same for Python, etc.

We would need to figure out the XML format. The idea is something 
along the lines of:
 
  <object>
   <interface name="org.freedesktop.FooBar">
     <method name="Blah">
      <arg type="int32"/>
     </method>
     <method name="Foo">
      <arg type="string"/>
     </method>
   </interface>
  </object>
  <subtree>foo</subtree>
  <subtree>bar</subtree>
  <subtree>baz</subtree>

III. Move typecodes to a single block
===

Right now the message body is "typecode, data, typecode, data" 
and suggestion is to move to "typecode, typecode, data, data"

This slightly decreases message-creation efficiency since each append 
arg operation affects two places in the message.

The reason for the change is to speed up method resolution and
typechecking. If you allow overloaded methods as C++ does then you
need to include the signature in the method lookup.  Even in C it may
be faster or nicer to do all the typechecking up-front.



Havoc