Re: Orbit Development

[Dick Porter <dick cymru net>]

On Thu, May 14, 1998 at 09:41:46AM +0100, Phil Dawes wrote:
> I thought I'd send a post here to attempt to spark up some interest in
> the development or orbit, and also to divert corba-style discussions to
> the components list (which I think it was set up for).
> 
> Anyway, here's some questions:
> 
> 
> 1) Who is currently working on orbit? 

Currently, myself and Elliot Lee. I've been working on the ORB parts, Elliot
has been tackling the IIOP transport.

> 
> 2) Does anybody have a strategy for developing Orbit in tandem with
> Mico? The problem I see is that writing an orb from scratch with all the
> stuff we want in it is a mammoth undertaking - I was hoping that we
> might be able to do it a bit at a time, covering the missing
> functionality with Mico as we go. 

I dont think its feasible to try and incorporate large chunks of MICO code.
One of the aims of ORBit is to have a small, fast, efficient ORB, which is
why we are writing it in C. We also want a set of C CORBA bindings. Linking
in large chunks of C++ seems to me to be the opposite of the design goal.

On the other hand, I have been keeping MICO compatibility in mind while
writing code. I want to see MICO objects and ORBit objects being freely
interchangable, so that those who want to write CORBA code in C++ for Gnome
will be catered for by MICO.

> 
> 3) I've had a look at Idea-1 in the Orbit CVS tree about avoiding
> marshalling for in-proc objects. Does this mean that all client stubs
> have to talk through a structure of pointers? Otherwise how does the
> object adaptor substitute the marshalling functions for the 'real'
> object once it decides that both objects are in the same address space.

This is Elliot's idea for optimising the shared library-style objects.
Elliot will have to fill in the details, but I think the idea is to compute
the function pointers once at invocation time, rather than at every method
call. For remote objects, I assume the same pointers will just call IIOP
marshalling routines.

> 
> 4) Flick currently doesn't support 'Typecode' and 'Any', which means
> flick clients cannot talk to an interface repository (amongst other
> things). Are there any plans to integrate this into the compiler? (I've
> also mailed flick-users about this)

I think we should use the marshalling code from Flick. Whether we leave it
wrapped in the whole flick compiler, or write our own compiler around it is
still undecided. Whatever happens, we will need an IDL compiler that supports
Any and TypeCode.

> 
> 5) Is it possible to de-couple the object adaptor from the orb core so
> that they can be written in parallel? I was thinking along the lines of
> writing a shared library adaptor which wouldn't need the marshalling or
> transport functionality. Does the portable object adaptor spec allow us
> to do this?

Theres nothing stopping it being implemented in parallel now, except for
finding someone to do it :-) The current orb library has a complete (I think)
set of CORBA v2.2 stubs, most of which assert(!"Not yet implemented");. If
you want to do some coding, pick a module and code it!

> 
> 6) I've used FNorb to successfully communicate to the Mico interface
> repository and invoke methods on client objects through IIOP. Can we
> de-couple the marshalling code from the iiop transport to allow objects
> in other languages to be loaded into the same address space as C objects
> and talk without requiring IIOP overhead. 
> (I might have misused the word 'transport' - I'm not that familiar with
> the inner workings of an orb core)

I dont understand - so long as the calling sequence matches, it doesnt
matter what the implementation language is to a shared library.

> 
> 7) Can we have a seperate object adaptor for each language? I was
> wondering if the object adaptors for other languages could be
> shared-library corba objects themselves. I.e. they get loaded on demand
> depending on the characteristics of the object (as recorded in the
> implementation repository).

We will need a seperate IDL compiler (or language selection switches) for
each language. We might need a simple shim between a language specific ORB
mapping and the C mapping. Apart from that, any language that can link to
a C shared library will have no problems.

> 
> 
> Basically what I am getting at is: Is there a design document for orbit?
> If not, I was thinking that it might be worth decoupling the orb
> components as much as possible and working on each bit as a complete
> entity in itself if possible. That way we may get something functional
> in a short amount of time, and encourage more people to contribute. At
> the moment the Orbit project as a whole entity looks like a massive
> mountain to climb, and I don't see many people willing to climb it at
> present.

The "design document" is the CORBA v2.2 spec from OMG. See my comments above -
if there's an area of the CORBA spec that particularly interests you, and you
feel like doing some coding, then you will be very welcome to join in.

> 
> Cheers,
> 
> Phil.

- Dick