test suite failure - more detail ...

[Olivier Andrieu]

 Havoc Pennington [Mon, 19 Apr 2004]:
 > On Mon, 2004-04-19 at 14:34, Olivier Andrieu wrote:
 > > 
 > > Btw, you explain this very well here ;) :
 > > http://freedesktop.org/pipermail/dbus/2004-April/000974.html
 > > 
 > 
 > Oh, right ;-) 
 > 
 > What if we do something like:
 >  - asynchronously ask for the service owner (and begin monitoring it)
 >  - ignore signals received before the service owner reply arrives
 > 
 > The semantic then is that if I'm app A and I do:
 > 
 >   1. invoke a method that emits a signal
 >   2. create a proxy (including ask for service owner async)
 >   3. invoke a method that emits a signal
 > 
 > Then I can't ever get the signal in 1., because I haven't received the
 > async service owner reply at that point. And I always get the signal in
 > 3., because the bus driver has to process my GetServiceOwner and put the
 > reply in my queue before it's allowed to process my method call.

That sounds great. The proxy needs a way to tell the user whether it
has received the service owner reply. A good way to do this I think
would be to have a g_signal ::state-changed and a
dbus_gproxy_get_state method, state being either `disconnected' or
`connected'. Disconnected means that the proxy doesn't receive signals
and that method invocations may fail. Connected means the service is
known to exist and that signals are processed. The proxy would be
created in the `disconnected' state and upon reception of the async
service owner info, it would switch to `connected'. The proxy would
also switch state when a ServiceOwnerChanged signal arrives.

Hmm, actually the proxy should have 3 states : 
 - initial (we don't wether the service exists, no signals, method
   invocation may fail with a ServiceDoesNotExist error),
 - disconnected (we know the service doesn't exists, no signals nor
   methods),
 - connected (we know the service exists, process signals and methods)

That would also works nicely with activation: when creating a proxy
with activation, we asynchronously send the "ActivateService" message
and upon reception of the reply, we switch the proxy's state.

 > So an API that makes these natural would be good. I don't think we
 > should design API purely to get the optimization, we should design
 > the API to be nice and then figure out how to optimize the
 > implementation.

Sure.

-- 
   Olivier