thoughts on conversations

[Colin Walters]

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

Yeah, we could call it that I guess, although I kind of wanted to
emphasize the statefulness involved since I think that's the core issue.

> 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, ... 

Hmm.  Is it useful to signal clients and 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... ?)

Well, what I was thinking is that the bindings would add a standard
header "org.freedesktop.DBus.ConversationID" to the message headers in
order to determine which conversation a message was sent to. This feels
a slight bit cleaner to me than synthesizing an object path which refers
to the same object as a well-known path, but I don't have too strong an
opinion on it.

> 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?

This is where the message header idea comes in.  We do want to support
multiple client conversations with an object, so I don't think we can
bind it to the server object.  It is conceptually bound to the client
proxy, but client proxies don't have object paths because the client
proxy isn't acting as a service.  

> 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.

My feelings are that disaster recovery has to be handled at the app
layer basically, I don't see how we can sanely handle it at the dbus
level.  A parallel to this is how kernels don't try to preserve TCP
connections on machine reboot; apps which need to be fault-tolerant have
to layer on top of TCP and handle TCP connection breaks.

In other words it seems to me that having libdbus or whatever preserve
the connection ID is the small part of the problem; the hard part is
having the service checkpoint all the other state associated with the
client, and having clients know how to handle a connection failure.  So
having us provide some semantics for having the same connection ID on
service crash isn't all that useful. 

Just my initial thoughts, I am certainly not an expert in fault-tolerant
software design.  I guess the key point with your GConf example is that
GConf has strong semantics associated with it, so you can define how to
handle faults, but DBus is a generic protocol.

> 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

Well, my original thought was that a conversation was with a particular
object, not with a connection as a whole.  So using connection
properties wouldn't work for that.  

-------------- 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/20050810/455d09eb/attachment.pgp