test suite failure - more detail ...

[Havoc Pennington]

On Mon, 2004-04-19 at 10:02, Olivier Andrieu wrote:
> OK, I implemented that. I wasn't too sure about the STRING_OR_NIL
> overloading since I did not see this used anywhere else. 

I'm not super sure about it either; I guess it might break some language
bindings... hrm. In this particular case we could use "empty string" for
a nul service, but that is pretty gross in languages that do have nil.

> - When you create a proxy with dbus_gproxy_new_for_service() for a
> service not known to the manager, it asks the bus about it with a
> GetServiceOwner method. This introduces a round-trip to the bus that:
> a) may fail and b) may not even be necessary if the service is not
> supposed to send signals.
> A solution would to add an argument in dbus_gproxy_new_for_service()
> indicating wether we want this proxy to be able to receive signals,
> but that feels like a kludge.

new_for_service() should listen for signals from the well-known service
name, not from the base service. i.e. you should not need to know the
base service name for new_for_service, and if the service owner changes
then the proxy applies to the new owner instead.

new_for_service_owner() on the other hand binds to the current service
owner (the base service name) and the proxy is useless when this owner
disconnects.

Does that address the issue or am I understanding it incorrectly?

> - The next problem is that it is not interacting nicely with service
> activation. The test program in test/glib does this: send a
> ActivateService message, receive the activation reply, then create a
> proxy for the service. What happens is that the ServiceOwnerChanged
> signal arrives before the proxy is created, so the service is not
> tracked yet by the manager and the signal is ignored. Right after
> that, the proxy is created and the client sends a GetServiceOwner
> message, which is dumb because the bus just sent this information ! 

Hmm, yeah that's lame. One approach would be to have an activation
function that returned a proxy, so it could just sort all this out in
one function.

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.

I still have to look at your patch, that will take more time, I just
thought I'd reply to these things first. ;-)

Havoc