Re: glib / CORBA integration examples ...

[Alex Graveley <alex ximian com>]

Hi,

On Tue, 2002-09-17 at 07:14, Michael Meeks wrote:
> 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 ?

Its very simple, you have two drastically different object systems
integrated poorly or not at all except setting up the IDL vtable.

Do a diff of the features and policies of Gtk and CORBA Objects, and you
have your list.

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

Is such a virtualization possible for 2.2?

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

Type safe my ass.  Object handles are a friggin gpointer typedef.  Lists
are slightly more typesafe (you're still filling it with gpointers after
all), at the loss of simplicity/generic-ness and and the addition of API
bloat.

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

It can't get much harder than it is now.

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

Why not a per-method lock, or a per-object lock, or no locking and leave
it up to the implementation?  These are all easy enough to support
generically... a PrePostInvoke GTypeInterface maybe?

> >  Typecheck incoming lists/arrays containing Objects using
> > GObject typechecks.
> 
> 	Why typecheck what you just de-marshaled ? that's crazy ;-)

I meant for outgoing calls, to add back some of the loss of
"type-safety" you lose with GLists.

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

Another example of the CORBA C binding lameness.

> > 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' ;-)

I was talking of a generated server skeleton, that object
implementations would subclass and override the virtual methods of.  The
generated destroy method would unref any Object handle attributes and
g_list_free() any list attributes (and release their contents) defined
in the IDL.

Idealy Object handles would be GObject pointers just like object
implementations.  So we can drop all the BonoboFoo/Bonobo_Foo cruft. 
The stubs calling whatever is in the GTypeInterface vtable -- the
marshalling code for handles, the actual implementation for local
objects.

(Just some not-very-well-thought-out thoughts)

-Alex

-- 
 on the canvass of life, incompetence is my paintbrush.