test suite failure - more detail ...

[Michael Meeks]

Hi Olivier,

On Thu, 2004-03-25 at 18:55 +0100, Olivier Andrieu wrote:
> Hmm I wonder if this test ever passed :)

	;-)

> Apparently, the test-dbus-glib is waiting for a "Foo" signal to be
> emitted by test-service. But the gproxy delivers signals only when the
> incoming message match the same (service, path, interface) triplet
> than what was set when the proxy is created. 
> 
> Here the proxy is created for the
> "org.freedesktop.DBus.TestSuiteEchoService" service but when the
> signal message arrives, it has the base service in its sender header.
> So, no match, no signal.

	Right; so - since I didn't understand this - I added some debugging to
print the relevant tri-strings; and got:

dbus-gproxy.c (dbus_gproxy_manager_register):
register:
'org.freedesktop.DBus.TestSuiteEchoService,/org/freedesktop/TestSuite,org.freedesktop.TestSuite'

and then during the Foo emissions I got: (dbus_gproxy_manager_filter)

proxy got :1.1,/org/freedesktop/TestSuite,org.freedesktop.TestSuite =
list (nil)

	So - the root cause us ':1.1' != 'org....'; so I know not what the
correct solution is; either

	a) the bus should fill out ':1.1' as the service 'o.f.D.T'
	b) the client should fill out ':1.1' as the service name
	  (it knows who it is)
	c) the client should not register a specific service-name,
	   [ but then it shouldn't register :1.1 either I guess ].
	d) the gproxy code should hash only on the latter 2 strings
	   in the tri-string, and sloppy match against the first.
	e) the hash function should (could) do some looser matching
	   funkiness. 

> It should work with dbus_gproxy_new_for_service_owner but it's not
> implemented yet !

	I'm guessing this is going to be a common problem though; surely, if
emitted events don't have the service name, but a numerical handle
instead ?

	Regards,

		Michael.

-- 
 michael at ximian.com  <><, Pseudo Engineer, itinerant idiot