Re: glib / CORBA integration examples ...
- From: Michael Meeks <michael ximian com>
- To: Alex Graveley <alex ximian com>
- Cc: Mark McLoughlin <mark skynet ie>, Havoc Pennington <hp redhat com>, bonobo <gnome-components-list gnome org>, orbit <orbit-list gnome org>, Elliot Lee <sopwith redhat com>, Tim Janik <timj gtk org>
- Subject: Re: glib / CORBA integration examples ...
- Date: 17 Sep 2002 12:14:56 +0100
Hi Alex,
On Mon, 2002-09-16 at 20:49, Alex Graveley wrote:
> This thinking is folly in my opinion. Everyone *hates* the CORBA C
> bindings.
So - tell me precisely - why !? beyond stating people's vague feeling
of hatred ;-) can you give a bulleted list of reasons ?
> Everyone is *confused* as to how bonobo and gobject interrelate
Ok - it's a shame that Tim refused to virtualize the ref counting on
GObject. We could have had a thread safe ref/unref, as well as hook in
the Bonobo aggregate stuff; but ...
> wrt allocations, refcounting, local vs remote BonoboObject
> calls, etc.
ref-counting is a big mess; local & remote BonoboObject calls are
transparent to the user, so hard to get too confused about :-)
allocation is indeed different - but type safe unlike glib, and hardly
confusing.
> Drop the C bindings, and C binding compatibility. Make the IDL compiler
> generate code which accept GLists for CORBA sequences, and GArrays for
> CORBA arrays.
It would make more sense to use DCE, and just marshal the GList nodes.
Ultimately - you're going to have memory management complexity when you
can have local/remote objects. I'm not convinced that glib's type system
is going to make that at all easy.
Things like using GLists sound fine - until you realise that we'd have
to have a global lock to allocate each list element - or de-marshal
anything; in the (potential) threaded world that's quite unfriendly for
performance [ plus GLists are intrinsically far less efficient - using
GArray for everything would make much more sense ].
> Typecheck incoming lists/arrays containing Objects using
> GObject typechecks.
Why typecheck what you just de-marshaled ? that's crazy ;-)
> Ignore stack allocation. Remove complex allocation and ownerships;
? what ? the _release stuff is so broken that no-one should use it;
'ownerships' ? someone has to own everything, unless you're proposing
adding garbage collection at the same time.
> when in doubt, copy or add ref. Have the IDL compiler
> generate GObjects, and handle resource freeing in the generated destroy
> handler.
What resource freeing ? I think I've said this before, but you're
dramatically confusing the 'interface' with the 'class/instance'
concept. They don't map. There are no resources to free in the
'generated destroy handler' ;-)
> P.S. - This is not a flame :-)
Nor is this :-)
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]