test suite failure - more detail ...
michael at ximian.com
Mon Mar 29 07:09:55 PST 2004
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:
and then during the Foo emissions I got: (dbus_gproxy_manager_filter)
proxy got :1.1,/org/freedesktop/TestSuite,org.freedesktop.TestSuite =
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
> 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
michael at ximian.com <><, Pseudo Engineer, itinerant idiot
More information about the dbus