Re: thoughts on conversations

On Tue, 2005-08-09 at 20:03 -0400, Colin Walters wrote:
> 
> 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.

If I understand correctly, you're talking about what I would have called
a "client registration" pattern ... ?

i.e. the server wants to keep a list of clients, send things out to all
clients, send things to a specific client, be notified when a client
vanishes, and track attributes of each client, something like that.

Thought: maybe the API is around a "client list," i.e. server side API
for add client to list, remove client from list, signal clients, list
clients, ... 

A random side point, I wouldn't do uint32 ID, maybe just use an object.
i.e. create an object path for the conversation (on the server side, or
even on the client side could work... ?)

You might could avoid an object path for the conversation itself and
just bind the conversation state to either the client or server
object... then you don't need the conversation ID to be passed around as
method args, just use the source/dest object in the message?

BTW a major mistake in gconf IMO is the way disaster recovery works. The
daemon logs the client list to a file, and if the daemon crashes it
recovers the client list from the log file. The way it should work
instead is that if the daemon crashes, each client knows to find the new
daemon and re-register. i.e. all state is effectively preserved by the
clients.

Another thing to consider is how this might interact with the idea of
properties; in two ways:
 - we've considered having "property lists" associated with bus 
   connections
 - there's the org.freedesktop.DBus.Properties interface in the spec

The latter could be used instead of the a{sv} if you used an object path
for the conversation ID.

Havoc