Re: ORBit mail 3 - Vtable layouts

[Lauri Alanko <lealanko cc helsinki fi>]

[reply-to directed to orbit-list@cuc.edu, that's where this belongs..]

On Mon, 15 Jun 1998, Phil Dawes wrote:
> Agreed. Unfortunately the whole point of inproc components is that they
> are not distributed. Areas where this could be of use are e.g. plugins
> for applications (e.g. gimp etc..), and in a component architecture.
> Witness how COM is used on OLE in windows for example.

"Not distributed"? You mean an object that cannot be invoked outside its
process context? If you want something like that, why use CORBA?

> Unfortunately the corba spec is not designed to be used with inproc
> objects (it doesn't define a binary standard), so I was hoping that we
> could develop one around the C-language POA mapping. Unfortunately it
> looks like this requires using casting macros which aggregate to a
> 'queryinterface' style function which as you mention goes against the
> corba spec.

Frankly, I don't understand all this fuss about optimizing in-process
calls at any costs. If you have objects that are going to communicate
in-process, and you want it fast, you have no reason to use CORBA anyway.
You can have the implementation code call other objects' implementation
code directly and forget all this reference/object adapter fuss.

You can't bypass all marshalling with in-process CORBA objects, at least
if they use vanilla POA. Calls can be forwarded, a POA could change state
and all that.. You can't just bypass the POA, at least if you want
conforming code.

Of course, you can have an extension, or custom OA, that is optimized for
in-process communication, but to me at least that seems rather
secondary at this stage..

As I said, if you want in-process performance, you don't want to use CORBA
anyway..


Lauri Alanko
la@iki.fi