Re: ORBit2, IDL compiler improvements

[Michael Meeks <michael helixcode com>]

Ok; sorry to follow up to myself but it might be better to express the
problem more lucidly.

> 	Lots of wonderful goals and news; very pleasing, however one of
> the most evil problems we have to face is that of the ABI for shared
> library modules; It really needs fixing IMHO. One rather simple method for
> solving the problem would be to make the local case do a generic in-memory
> marshal / de-marshal, but it is a nasty problem.

	The problem is this; currently we use the 'C' calling convention
for all our shared library 'ultra fast' in process shortcuts. This shared
library feature is _extremely_ useful in Bonobo land. However, one of the
beauties of CORBA is its language independance.

	Now; the problem comes when a non-C language ( eg. Owen's
ORBit-perl ) tries to access these methods. Consider the C function:

	StrangeCorbaStruct myFunction (PortableServer_Servant _servant,
                                       CORBA_long             i,
                                       CORBA_Environment     *ev);

	Now; in order to map the return struct ( one of my pet hates ) to
Perl we need to generate some sort of C->Perl stub / skel just to use the
shared library.

	So; this is essentialy the problem, providing a sensible
Application Binary Interface (ABI) that will allow a totaly generic
approach to using shared library methods. This will allow a single C
function to be written and interfaced with perl to allow all shared
library access.

	AFAICS there are many ways of doing this, of course currently it
is possible to do it already but only using nasty, complicated assembler
code.

	An alternative might be to have each SHLib function do something
like:

	void myFunction (PortableServer_Servant _servant,
                         guint8                *iiop_data_in,
                         guint8                *iiop_data_out,
                         CORBA_Environment     *ev);

	So; the stub would then:

	Marshal its arguments into the iiop data buffer, pass it to the
shlib function, and de-marshal its return arguments.

	This would then save us the overhead of task switching, network /
pipe and libc. However, for the simple case I am not over convinced that
it would be markedly slower;

	The process of filling out the iiop_data_in structure in the easy 
cases ( especialy if it is alloced ) is not over-disimilar to the process
of stacking arguments that already occurs in the stub.


	So; hmm. well, perhaps I misunderstood the problem or didn't see
something obvious, but I hope I expressed my conceptions of the problem.

	Regards,

		Michael.

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