test suite failure - more detail ...

[Havoc Pennington]

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.

However, if app B invokes a method that emits a signal, there's no way
for app A to know it will get that signal. Because there's no required
ordering between app A's GetServiceOwner and app B's method call.
But that's OK, in fact it's a deliberate design choice.

> DBusGProxy* dbus_gproxy_new_for_service (DBusConnection     *connection,
> 			                 const char         *service_name,
>                                          const char         *path_name,
>                                          const char         *interface_name,
> 					 gboolean            activate,
>                                          GError            **error);

Creates some issues, do we also add this to new_for_service_owner(), and
how do we express the activation flags? It sort of leaves us with one
function for each cell in a gproxy-constructor * activation-mode matrix.
Maybe a flags argument could address that.

It does seem appealing on simplicity grounds. I'd have to think about
this more.

I imagine what programmers _usually_ want to do is one of two things:
 - listen for a signal on an object if/when that object is already 
   running
 - use an object, starting it if required

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.

Anyway, no strong views on the right API here yet.

>  > A simple hack would be to just track the last few ServiceOwnerChanged
>  > messages we've received, and have the ProxyManager look at this history
>  > when creating a new proxy.
> 
> hmm ... yes that's a hack.

But is it a hack that breaks, or a reasonable optimization?

We should probably start from "what is the right API" then see what
hacks we need to make it go.

Havoc