Re: GEP 9: merging bonobo-activation & libbonobo

Michael Meeks <[email protected]>
Newsgroups gmane.comp.gnome.components,gmane.comp.gnome.desktop
Organization Ximian.
Message-ID <[email protected]>
Hi Mark,

On Wed, 2003-03-12 at 20:35, Mark McLoughlin wrote:
> 	I think it would be worthwhile to cc this to another list. There would
> be a lot of people with opinions on this but not on
> gnome-components-list. I've cc-ed desktop-devel-list.

	I believe I spammed every man/woman/child on the GEP list, but then
again I might have reflex discarded it on the admin page; hmm.

> 	You say "two seperate modules creates more problems than it solves".
> The two problems that you give are "packaging is hard" and "I want to
> use BonoboObject. Are there no other problems ?

	Well - there's the problem that before adding any new features to
bonobo-activation-server I want to re-factor the code so it's legible,
and non-cumbersome. I think it's a pretty big problem personally.

> 	I'm not sure either of these or really good reaons for merging the two
> and thus forcing people to use libbonobo where they may just want
> bonobo-activation. But then again, bonobo-activation hasn't seen much
> use without libbonobo.

	Sure - the only person who I thought might object was Bill H, but after
talking to him this appears not to be a big issue. Certainly it won't
affect anyone linking from A to B, and IMHO it doesn't affect any
potential portability, so ...

> 	FWIW, the GObject adaptor would provide a solution to the "I want to
> use BonoboObject part". Granted its not finished, but I'm willing to
> do the last bit of work required ...

	Well; as you know I still have major reservations about the GObject
adaptor. Particularly because it will provide yet more confusion in the
ORBit2/libbonobo space, but also crucially because I don't like the
fairly large non-typesafe extra amount of ORBit_gmethod_register typing
in the C code - instead of just including the IDL generated epv
structure [ something that IMHO BonoboObject gets right ]. Of course,
there are some good points about it - and I'm not altogether oppose to
something like this in ORBit2 - but I'm really not happy with this yet.
I see far more usability mileage in providing extended GSignal/GObject
property proxies in libbonobo personally.

	Finally, I don't particularly want to block bonobo-activation
re-structuring on the possible completion of the a new ORBit2 adaptor,
and I'd far rather that work was put into eg. ORBit2 asynchronous impl's
than this :-) but ... 

	So - that's why I think this is a separate issue, orthogonal to
merging.

	Regards,

		Michael.

-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.