Signals and bindings

[Havoc Pennington]

On Fri, 2004-09-24 at 12:26 +0200, Olivier Andrieu wrote:
>  - dbus_g_proxy_new_for_service proxies for a service, taking into
> account the fact that the owner can change over time. Sending method
> calls is easy (just put the service in the destination field). However
> receiving signals is more difficult because signals come with the base
> service in the sender field. The proxy has first to get the base
> service via GetServiceOwner and then it must "track" which base
> service owns the service. (That's where the ServiceOwnerChanged signal
> helps). Right now this tracking is not implemented, I'm working on it.
> 
> So, _new_for_service_owner needs a round-trip to be able to send
> method calls and _new_for_service needs a round-trip to be able to
> receive signals. For the latter, it could be possible to send the
> GetServiceOwner request asynchronously and avoid the round-trip but
> that means no signals would not be delivered until the reply arrives.
> 

Hmm, didn't think about that. It may be OK to simply do the
GetServiceOwner async. There isn't a real semantic guarantee about
whether you get a given signal emission or not anyhow, since the bus
itself is async.

Normally to track something you have to do:
 state = GetCurrentState()
 connect ("StateChanged")

The GetServiceOwner should be guaranteed to get a reply before
GetCurrentState does, so semantically it would work out most of the time
if GetServiceOwner were async. GetCurrentState() can be async or not
depending on what the app does.

Basically the GetServiceOwner is guaranteed to complete before any other
requests you make, so in most cases it would work as expected... ?

Havoc