d/bus cleanups ...

[Michael Meeks]

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.

	Right.

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

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

	Regards,

		Michael.

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