d/bus cleanups ...
michael at ximian.com
Mon Mar 29 05:04:22 PST 2004
On Fri, 2004-03-26 at 15:03 -0500, Havoc Pennington wrote:
> Thanks for the hacking. I'm getting to your other mail also.
Great; and no problem.
> We really need "make check" passing and testing the glib stuff - see the
> mail from Olivier who has tracked this down. I'm not comfortable
> accepting piles of patches without automated tests, though I understand
> we have to get to minimal workingness before we can test.
> "make check-coverage" makes it easy to see what the test coverage is...
> esp. when combined with "decode-gcov foo.c"
OK; my problem is ( I guess ) that 'make check' takes rather a long
time; which is curious. It takes ~1 minute 45 seconds to get to the glib
test failure on my machine.
> I don't think replies of any kind to a signal make sense; you can't
> return errors or return values.
Right; I need to re-think this - I still think we can do substantially
better wrt. signals than we are - at least; making them more 'glib-like'
than pushing the de-marshalling burden onto the signal connectee -
ultimately we have all the type data in hand, we should do much better;
code in the works.
> Of course GObject allows return values on signals, for a signal marked
> remote I think we have to disallow or ignore said value.
> I don't understand dbus_gobject_handle_signal() - it seems to emit
> a signal from the GObject.
It belongs in gproxy really I guess.
> It should be possible to register an object with multiple
> DBusConnection, so the quarks approach has to be more
> complex (store a list, essentially).
Ok as you say, this code sucks;
> Multiple registration of the same object on the same connection
> should _not_ be allowed, though.
> I don't think storing a copy of the path plus two bits of object
> data is really acceptable overhead; we should find some way
> to avoid it. Perhaps an unregister_by_data or something?
> Though that is a linear search in dbus-object-tree.c. Maybe
> registration returns an ID cookie (which could just be a pointer
> to an internal dbus-object-tree structure). Needs thought.
Yep; clearly keeping the path around is somewhat painful.
> dbus-gvalue.c is a nice plan.
> error_printf, nice.
Ok - I committed these two, the .cvsignores, and the mono/configure
fix; I'm re-factoring the rest.
michael at ximian.com <><, Pseudo Engineer, itinerant idiot
More information about the dbus