thoughts on conversations

[Colin Walters]

Hi,

I was thinking recently about the problem a number of people have run
into where they essentially want bidirectional stateful communication.
The model that the current D-BUS bindings are based around is basically
exporting an existing object from applications; a client can call
methods or inspect properties on the object, but there's no inherent
per-client state.  This usage is similar to KDE's DCOP as I understand
it.

But people are using D-BUS for many other things:

o NetworkManager's bidirectional communication between the system
  NetworkManager service and the NetworkManagerInfo user daemon
o gnome-power-manager wants to track active applications to e.g.
  determine which have unsaved data
o notification protocol
o totem <-> mozilla plugin communication

Probably the best example is Ross' post from June about needing a way to
asynchronously communicate progress messages back to an individual
client, without broadcasting to all client.

So, I thought I'd dump my semi-handwavy thoughts on how we make D-BUS
nice for these use cases.  Basically, we introduce the concept of a
"conversation" with an object.

First, we document a standard interface named
"org.freedesktop.DBus.Conversable", with methods "BeginConversation" and
"EndConversation".  BeginConversation takes an a{sv} as an argument
(representing arbitrary key/value pairs specific to the object), and
returns a DBUS_TYPE_UINT32 which represents that conversation.
EndConversation takes the uint32, and tells the object the conversation
is over.  Pretty simple.

The key to making this easy is for the bindings to have special support
for this interface.  For example in the GLib bindings, we'd allow
marking methods (or even whole interfaces or nodes) with the
"org.freedesktop.DBus.Conversable" annotation.  If this annotation is
present, it means the method takes a DBusGConversation * as the second
argument (the object still being first).  If the annotation is present,
the object must implement the org.freedesktop.DBus.Conversable
interface.  So for example, gnome-power-manager's primary object would
take the application name in the a{sv}, and set up the per-client state.

We'd probably want a way for the app to e.g. specify conversation
timeouts, etc. in their implementation of BeginConversation.  

On the service end we'd also need a new API like
dbus_g_conversation_emit_signal which would send the signal just to that
client.

On the client end, we'd have a new method like
dbus_g_proxy_new_conversation, which would do what you'd expect; e.g.
send EndConversation when it's g_object_unref'd.

Anyways, does this all sound sane?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050809/34b201e1/attachment.pgp