Re: GEP 5: New Object Adaptor for ORBit2

[Michael Meeks <michael ximian com>]

Hi Mark,

On Fri, 2002-09-27 at 06:08, Mark McLoughlin wrote:
> 	But that's not what this GEP is about. Strangely, you're not
> discussing requirements here. You're discussing whether the prototype
> meets the *proposed* requirements.

	Ah; sorry - I'll ask to add a few proto requirements:

	* Doesn't add API we don't need in Gnome
	* Doesn't provide duplicate / fragmentary APIs
	* Doesn't add API which will need revising later

	:-)

	Either way - I still havn't seriously looked at the code, which is
rather concerning, since I have simply no idea how it works / where the
balance between auto-generation / etc. is, it's use of the signal system
etc. etc.

>  I would like this "integration with
> Bonobo" requirement be that "due consideration be given to allowing the
> adaptor and servant be integrated into libbonobo in the future rather"
> than "the adaptor must be compatibly integrated into libbonobo now".

	Well; we can't break libbonobo ABI / API until 3.0 which is 2-3
releases away; why tie ourselves to another API in the meantime that
only helps a tiny sub-set of our users - those that don't use
BonoboObject, creates yet another API, etc. etc.

> 	Consider this to be dissent. And also seriously consider
> getting yourself new memory and text interpretation modules ..

	:-) I'll look at the code next week.

> <havoc>
> I would be really really dubious about massive swapping out of the
> libbonobo implementation in the 2.2 timeframe. My suggestion would be
> to add this feature to ORBit for some apps to play with in 2.2, and
> then look at using it pervasively in the 2.4 or 3.0 timeframe.
> </havoc>

	To use it pervasively in the 2.4 timeline makes no sense, since we need
aggregation, and thus we're going to need BonoboObject, yet we [AFAIR]
can't make BonoboObject work well with the new adaptor [ as it is ]. So
- if we're not going to use it pervasively until 3.0 - why commit to
it's API now ? - why even add the API ? it seems strange to me.

	Anyway; I'm just concerned, that we're rushing to add an API, that by
itself is not that useful to Gnome [ cf. aggregation ], and will need
support code layered above it - when as yet, we have no users of it etc.
Perhaps some experimental #define guard or something would be good.

	Not that I'm adverse to using it - b-a-s is crying out for an end to
the evil 'standard' way of using the POA.

	Hmm :-)

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot