Re: glib / CORBA integration examples ...

[Michael Meeks <michael ximian com>]

Alex,

On Tue, 2002-09-17 at 13:20, Alex Graveley wrote:
> > 	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.

	What are you talking about ? I'd respond in detail, but it seems clear
that you havn't read the recent bonobo samples code, see
libbonobo/samples/echo/*.[ch] and then recant :-)

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

	I think you're extremely confused; ultimately, while we could do things
like proxying GObject properties, and some signals - we could never do a
good job of it, people would still be trying to 'cast' their local
'GObject' to 'GtkTree' despite the fact that such a thing doesn't exist
on the local side. There is a reason we have an opaque CORBA_Object
handle on the client side instead of a GObject - it's because it's
different in a large number of ways, and it can't feasibly be that
similar.

	To make them more similar, would IMHO create even more confusion,
because the similarity is going to fail badly at some point.

> Is such a virtualization possible for 2.2?

	Would it even help that much ? see above; why do you want your client
handle to be a GObject anyway ? You're still going to need to have the
difference between a local and a remote Ref, due to the way the ref
counting / passing convention works [ and the convention sucks, I know -
but it's not fixable now ].

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

	Your donkey offspring is probably extremely type safe then, consider:

typedef struct {
      CORBA_unsigned_long _maximum, _length;
      Bonobo_StorageInfo *_buffer;
      CORBA_boolean _release;
} CORBA_sequence_Bonobo_StorageInfo;

	And the corresponding alloc / free methods etc. vs. the GArray's
'gpointer', and re-consider your ass. 

>  Object handles are a friggin gpointer typedef.

	And ? you can still check the type of it if you want :-) I forget why
Elliot made it a gpointer typedef; it doesn't make sense to me, but I
assume there's a reason; it seems better to me to have them all a
typedef of CORBAOpaqueRemoteHandle or something.

>  Lists are slightly more typesafe (you're still filling it with gpointers
> after all),

   typedef struct Bonobo_StorageInfo_type Bonobo_StorageInfo;
   struct Bonobo_StorageInfo_type
   {
      CORBA_string name;
      Bonobo_StorageType type;
      Bonobo_ContentType content_type;
      CORBA_long size;
   };

	Filling it with gpointers ? where ? consider:

	my_seq._buffer[3].name = CORBA_string_dup ("Foo");

	Spot the gpointer.

> at the loss of simplicity/generic-ness and and the addition of API bloat.

	API bloat ? - where ? ultimately type safety requires no API bloat,
certainly ORBit2 should impose none. Indeed, glib's run-time type
checking truly adds bloat, and fairly significant performance overhead.

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

	Wow - clearly you havn't seen where we've come from; do you remember
the days before BonoboXObject ? - have you any idea ? :-)

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

	Ah - wait, I see the GList allocators are in fact thread safe; so ...
forget it, that's not a problem.

> > >  Typecheck incoming lists/arrays containing Objects using
> > > GObject typechecks.
...
> I meant for outgoing calls, to add back some of the loss of
> "type-safety" you lose with GLists.

	How can you typecheck a list of structures ? how about a list of
strings ? yes you can typecheck a list of GObjects - but they're a tiny
sub-set of what we can pass, furthermore a CORBA_Object can support MI
while the GType system can't cope with that.

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

	Again - I've no idea what you're on about. The 'just sub-class to
implement an instance' thing creates yet more complexity in a dual
inherited world, effectively cutting out the possibility of
implementation inheritance - provided fairly cleanly by BonoboObject.

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

	You're confused - worse - you assume we use a '3rd party' model of
property storage, which is just a totally stupid way to manage object
properties; the property should be stored once - at point of use. The
main point is that again you confuse an 'interface' with storing some
data, they are radically separate concepts.

> Ideally Object handles would be GObject pointers just like object
> implementations.  So we can drop all the BonoboFoo/Bonobo_Foo cruft.

	How can we possibly drop that ? Do you propose having a BonoboFoo
reference at both ends ? sub-classing to implement would give that
possibility - but has horrible issues wrt. inheriting implementation,
and adding new sub-classed interfaces.

	Ultimately - while that model sounds nice-ish, you need to show how you
can derive both implementation, and add new sub-classed interfaces to an
Object - since this is (partly) what people want to do.

> The stubs calling whatever is in the GTypeInterface vtable -- the
> marshalling code for handles, the actual implementation for local
> objects.

	Hmm; ultimately none of this is impossible if we radically change the
API / ABI - but if we're doing that - we should probably re-write a lot
more than this. To accommodate these changes we need to:

	* Re-design the way reference counting works
	* Re-design the way inheritance works
	* Re-work all the client and server code

	If we're going to do that, there's sufficient problems with the current
approach that we might as well bin it all and start again. My hope is
that Mono will provide that disruptive technology point, and I won't be
worrying about it in 4 years time. Contrast this with:

	* Make CORBA structures map to Glib structures

	And I think you can see the contrast in terms of bang for buck API
compatible changes.

	Regards,

		Michael.

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