Re: foreign interface

[Jason Tackaberry <tack linux com>]

> Therefor I did sketch a ORBit-foreign interface that can be used for all
> script languages (I hope). Traversing, converting and creating foreign
> data structures will be done using interfaces. If you want to create a

Isn't that what orbit-small was all about (which is now merged with
ORBit2)? 

When I looked at orbit-small it did seem to provide a much cleaner
interface for language bindings, but the fundamental problem is not
solved (not that it's really a problem, per se).  I'm either taking
Python objects and marshalling them directly to/from a GIOP buffer, or I
am taking Python objects and converting them to/from generic data
structures which are then marshalled by ORBit for me.  This is handy
when the underlying object representation is compatible with the ORBit2
API, but in many cases it's not, so I'm still decoding/encoding Python
objects.

> foreign primitives to C. You dont have to think about how CORBA is doing
> masrhalling and demarshalling. 

The marshalling and demarshalling isn't really excessively complicated.
In ORBit-Python cvs, if you look at demarshal.c/marshal.c and compare
that with the decode/encode functions in api.c, it's not really much
simpler.

I think what orbit-small (i.e. the bindings level API that ORBit2
provides now) is going to give us is cleaner, and more efficient code,
especially in the case of in-process servers.

(The above is just my rough understanding of how ORBit2 works.  I
haven't looked at it seriously yet.)

Cheers,
Jason.