Orbit Development

[Phil Dawes <philipd parallax co uk>]

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? 

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. 

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.

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)

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?

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)

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


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.

Cheers,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.