Re: glib / CORBA integration examples ...



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]