Re: glib / CORBA integration examples ...

[Michael Meeks <michael ximian com>]

Hi Tim,

On Thu, 2002-09-12 at 05:23, Tim Janik wrote:
> > 	So we can cast between a sequence and a GArray - and of course, use all
> > the glib helpers for manipulating them.
> 
> is this for readouts only? and this approach is bound to break with future
> changes (the bin incompat but source compat ones).

	Hmm; it's really so that people can use the g_array methods on
CORBA_sequences; but the sticking point is really that a CORBA_sequence
can be stack (non)allocated, so we'd need to special case for that in
g_array I suppose.

> i don't have much of an idea of corba's smart allocations, is that
> about a type tag ahead of every allocated memory block?

	Yes, as defined by the spec. CORBA_free is used for strings, Sequences,
Sequence buffers [ Garray's data member ], Anys, certain Arrays etc. Of
course - having a 'boxed' type for every allocated type is rather an
elegant way of carrying type data around IMHO.

> > 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.
> 
> i'd say that is a pretty bad idea. for one, glib is in wide use in
> non-corba environments, for another, there're a lot of non-corba
> related strings in applications that'd be affected.

	True; it depends whether you see that as a big cost ? my personal
feeling is that really people should learn to use the CORBA environment,
and that anything else is small minded folly. But I've heard some
otherwise surprisingly rational people foam at the mouth about having to
CORBA_free things instead of g_free them :-)

	And it's true: users' don't like to learn more things - and multiple
allocators don't help anyone. But it's also true that the current 'raw
malloc' semantics cannot satisfy the CORBA binding. Clearly a byte
offset per string pointer is the most efficient space approach to
tagging simple allocations, is it too much ?

> i never actively used corba in any of my programs (though other related
> encapsulation layers), so i fail to miss glib convenience using it. it'd
> help me much, if you gave a few examples of what code currently looks
> like, and what you'd like it to become.

	Ok; so currently say you get a sequence of doubles returned to you:


CORBA_sequence_CORBA_double *val;
val = Foobar_do_method (foobar, ev);
for (i = 0; i < val->_length; i++)
	fprintf (stdout, "%g, ", val->_buffer[i]);
CORBA_free (val);

	so - the sequence typedef provides a type-safe wrapping of the sequence
contents;

	However, interestingly sequences are allocated more efficiently than
GArray - since their size is known; thus if you get a sequence of
sequences:

	val->_buffer[i]._buffer[j]

	would be the dereference style; since the first buffer contains the
packed sequence contents.

	Similarly the type system can describe structs and unions which map to
the equivalently laid out C structures; and of course deeply recursive
types. Thus we can have an 'Any' representing an arbitrarily complex
type. This doesn't seem possible (or useful) with the current GLib type
system. One of the big extra-marshalling uses of the ORBit2 style type
data is of course, it's use in allocation - by keeping the tied by smart
allocation to the instance, we can recursively free arbitrarily rich
data structures in a way that is trivial for the user to understand. [
We also keep all the structure member name data, enum name/value data
etc. in-core for scripting bindings ].

	Of course - in an ideal world [IMHO] there can be only 1 type system;
and my feeling is that there are a range of requirements provided by
CORBA that should be quite attractive to a glib user.

	Was that what you wanted, or was there more ? [ clearly unifying the
marshallers into a more generic framework would be nice too, with a
shared type system would be a nice saving / efficiency win, but we'd
need to do it more abstractly than either do currently I think.

	Regards,

		Michael.

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