Re: glib / CORBA integration examples ...

[Alex Graveley <alex ximian com>]

Hi,

This thinking is folly in my opinion.  Everyone *hates* the CORBA C
bindings.  Everyone is *confused* as to how bonobo and gobject
interrelate wrt allocations, refcounting, local vs remote BonoboObject
calls, etc.

Without a major overhaul we will be throwing out years of work because
the learning curve is simply too high...  today people have to be
muscled into using Bonobo/CORBA even when it is the obviously correct
choice.

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.  Typecheck incoming lists/arrays containing Objects using
GObject typechecks.  Ignore stack allocation.  Remove complex allocation
and ownerships; when in doubt, copy or add ref.  Have the IDL compiler
generate GObjects, and handle resource freeing in the generated destroy
handler.

I like everything else about the GEP, especially the idea of using
GTypeInterfaces.

-Alex

P.S. - This is not a flame :-)

On Fri, 2002-09-06 at 07:30, Michael Meeks wrote:
> So; just to get some of this out of my HEAD;
> 
> 	If we can change the glib / CORBA ABIs/APIs here's what I'd like to do
> as an example:
> 
> struct _GRealArray {              struct _CORBA_sequence_base {
>   guint8 *data;                     gpointer _buffer;
>   gulong  len;                      CORBA_unsigned_long _length;
>   gulong  alloc;                    CORBA_unsigned_long _maximum;
>   guint   elt_size;               ...
>   guint   zero_terminated : 1;    };
>   guint   clear : 1;
> };
> 
> 	So we can cast between a sequence and a GArray - and of course, use all
> the glib helpers for manipulating them.
> 
> 	Clearly - the 'smart allocation', that CORBA needs, would be beneficial
> to glib users I imagine [ Tim ? ], a sticking point might be strings
> there - we currently offset the pointer to tag it as a string, rather
> than using a full smart header to save space there; can glib accept a
> 'wasted' byte per string ? etc.
> 
> 	Of course - the real sticking point would be expanding the glib type
> system to cope with the wealth of types that CORBA needs to express,
> structures, unions etc. but that's not insurmountable either.
> 
> 	Anyway; just so my pipe-dream is better expressed,
> 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list
-- 
 on the canvass of life, incompetence is my paintbrush.