Re: Orbit Development

[Elliot Lee <sopwith redhat com>]

On Thu, 14 May 1998, Phil Dawes wrote:

> 1) Who is currently working on orbit? 

Dick Porter and I are the ones who have done the work so far.

> 2) Does anybody have a strategy for developing Orbit in tandem with
> Mico?

No, and it won't work. :) It will be more work to try and tie bits of Mico
& ORBit together than it will be to just go and write them outright. We
would also end up modeling our design too closely to the Mico one, instead
of doing it the best way for this particular implementation.

> 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?

No, this means that different types of stubs are accessed through this
structure.

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

There's no need to demarshal/marshal at all if you're calling a method 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)

Well, even using flick isn't 100% certain (although very likely) - but I
know Dick wants the Typecode/Any support, so it will get done ;-)

> 5) Is it possible to de-couple the object adaptor from the orb core so
> that they can be written in parallel?

Nope, because the POA depends on the ORB internals.

> I was thinking along the lines of writing a shared library adaptor which
> wouldn't need the marshalling or transport functionality.

But such a POA would be useless...

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

Right now we need to just get something working - I don't think it will
require a huge change once the basics are written.

> 7) Can we have a seperate object adaptor for each language?

Sure, if you write it. I don't think we need to though.

> Basically what I am getting at is: Is there a design document for orbit? 

OMG CORBA/IIOP spec version 2.2 ;-)

The problem to be solved is a very clearly defined one, so there isn't any
need to go writing all this bureaucratic paperwork to convince ourselves
that we are making progress... <g>

I would like to work on ORBit, but am busy with other stuff right now.
Dick seemed to indicate similarly. Writing paperwork won't give anyone
more time, and any people who wanted to help would have already started
helping by now.

Please be patient - if you're wanting to _do_ something to help, the
typedef's that both the IIOP and orb modules use need straightening
out/synchronizing, and perhaps the CORBA types that the IIOP stuff uses
need putting into a global header file too. 

Thanks!
-- Elliot
When I die, I want to die peacefully in my sleep like my grandfather...
	...not yelling and screaming like the people in the back of the
	   plane he was flying.