Re: Orbit Development

[Phil Dawes <philipd parallax co uk>]

Dick Porter wrote:
> 
> On Thu, May 14, 1998 at 09:41:46AM +0100, Phil Dawes wrote:
> >
> > 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.
> 

Oh good. I wasn't sure if it was being actively developed or not. (I
haven't got CVS access because I'm behind a firewall, and I've only just
discovered Jim Picks snapshot page.)

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

Fair enough. But we might be able to use the corba interfaced lumps,
like the interface repository, naming service and implementation
repository. That wouldn't require linking C++ with the client.

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

Hmmm... that might be tricky because Mico doesn't support the POA
(AFAIK).

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

Ah good. This is how mico and omniorb do it with C++, except the
function pointers are implicitly generated by the C++ compiler as
Vtables, which can be hot-swapped at runtime because they both inherit
from the same base class.

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

Do we loose the speed of flick if we drop the compiler? I thought that
its ability to dynamically generate optimised marshalling code on a
per-context basis was what set it apart from other idl compilers. (I
might have misunderstood what you meant here)

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

I've got a bit of understanding to do first, but I'll be back.


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

Ah right. You're reaching the boundaries of my knowledge when talking
about shared libraries with other languages. I'll come back when I've
done some reading.

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.