thoughts on conversations

[Ole Laursen]

(Resending since the message didn't appear.)

Colin Walters <walters at verbum.org> writes:

>> The server also listens for NameChanged signals and uses those to detect
>> when a client disconnects from the bus without releasing the objects.
>
> Yeah, this would be handled automatically.  Although in my opinion it is
> still a bug if the client doesn't release the proxy (end the
> conversation).

It is important for fault-tolerance - other components should be able
to recover gracefully from a bug in one client whenever it is
feasible. And the client could be abruptly terminated by the user.

>> I'm not entirely convinced by the need for arguments. Can't
>> Begin/End have no in arguments and its up to the other interfaces
>> on the object to define any required arguments?
>
> I guess, yeah.

Having no arguments appears to give a cleaner interface at the expense
of an extra round trip and a bit more logic at the client (it probably
has to provide a callback for an initial setup call after
BeginConversation). But why is it necessary to hardcode the arguments
to a{sv}? Couldn't you just leave them application-specific? That way
BeginConversation would act a bit like flexible type-safe constructors
in object-oriented languages.

I realise leaving the arguments unspecified probably would not work if
BeginConversation must be a predefined DBUS interface, but does it
necessarily have to be that?

>> Basically I'm torn over if a client obtains references to multiple
>> objects on the server, is that a single conversation or multiple
>> conversations?
>
> Multiple.  In this design a conversation is with a particular *object*.
> Does that match what you need?

It certainly matches what I need. Currently, I spawn a separate DBUS
object for each client when they connect - this way the signals on an
object is only caught by one client. It seems I could save all these
objects with your proposal.

-- 
Ole Laursen
http://www.cs.aau.dk/~olau/