test suite failure - more detail ...

[Olivier Andrieu]

 Havoc Pennington [Mon, 19 Apr 2004]:
 > 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.

Well language bindings will have to support overloading anyway since
many non-trivial interface will need some variants types. It was just
that maybe it would be preferable to keep the org.freedesktop.DBus
interface as simple as possible.

 > > - 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?

Err, there's some misunderstanding I'm afraid (either from you or me).

This very thread originated because the test suite failure to deliver
signals to proxies.  Indeed, incoming signal messages have the base
service in the sender field.  There is no "signal from the well-known
service" from the wire protocol pov.  To deliver the g_signal to the
concerned proxies, we have to maintain a base_service -> well-known
service mapping.  The service owner changes help with that but we need
to know the information as soon as the proxy is created because the
service may already be active and signals could be incoming right
away.

Btw, you explain this very well here ;) :
http://freedesktop.org/pipermail/dbus/2004-April/000974.html

 > > - 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.

smthg like this then :

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

 > 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.

-- 
   Olivier