ORBit mail 3 - Vtable layouts

[Phil Dawes <philipd parallax co uk>]

Evaluating the benefits of vepv vtable layouts
----------------------------------------------

As I understand it, ORBit currently supports a vtable layout
equivalent to the example below:

interface intf3 : intf1, intf2 {};


Object      VEPV            EPVs
------     ------         ---------

vepv ---> intf1_epv -------> op1
          intf2_epv ----.    op2
          intf3_epv --. |
                      | `--> op3
                      |      op4
                      |      op5
                      |
                      `----> op6


But given the casting implementation in Upcasting.txt, why not simply
eliminate the middle layer and have the server set up a number of
seperate method tables, and return a pointer to the appropriate one:


Intf1_Ptr   epv
---------   ---

epv ------> op1
obj         op2

Intf2_Ptr   epv
---------   ---

epv ------> op3
obj         op4
            op5

Intf3_Ptr   epv
---------   ---

epv ------> op1
obj         op2
            op3
            op4
            op5
            op6

And the casting macro simply calls a defined function on the server
which returns the appropriate epv according to the Repoid of the
interface.

#define CORBA_CAST_INTF1(_o) {_o->epv->CastTo(ID_OF_INTF1), _o->obj}
#define CORBA_CAST_INTF2(_o) {_o->epv->CastTo(ID_OF_INTF2), _o->obj}
#define CORBA_CAST_INTF3(_o) {_o->epv->CastTo(ID_OF_INTF3), _o->obj}

(as a space optimisation, the intf3_vtbl could be used for intf1 as
well)


This implementation increases overall efficiency by removing a
pointer-derefence from the invoking macros. However it does have a
limitation in comparison to the original layout, and that is the
problem which microsoft coined as 'the fragile base-class problem'.

The problem comes if one of the base interfaces of an object has an
additional operation added to it. If intf1 is changed to add a new
operation 'foo' to it:

interface intf1
{
    op1();
    op2();
    foo();
}

And the implementation object intf3 is changed to include this
method. It changes its entry point vectors appropriately to include
the new method:

Intf1_Ptr   epv
---------   ---

epv ------> op1
obj         op2
            foo

Intf2_Ptr   epv
---------   ---

epv ------> op3
obj         op4
            op5

Intf3_Ptr   epv
---------   ---

epv ------> op1
obj         op2
            foo
            op3
            op4
            op5
            op6


The problem is that binary clients of the original implementation now
have a conflicting set of stubs. This means that they must be
re-compiled with idl generated stubs for the new version of the
object. This is fine for clients with source-code, but may become a
problem if ORBit is ever to be used with binary-only clients
(e.g. commercial programs).

If you have another look at the original vepv --> epv implementation
you'll notice that it doesn't suffer from this problem.



Does ORBit need this extra vepv layer?
---------------------------------------

This depends really on what people decide are the requirements of the
orb. Note that the vepv method still doesn't guard against binary
incompatibility if the interface is physically changed (e.g. method
removed), or if the inheritence hierarchy is changed.

COM handles versioning through a dynamic cast function called
QueryInterface which can supply old epvs if required. ORBit's casting
Macros could call a function like this on the target object (passing
the repoid of the interface) to achieve a similar version control
goal.

However, note that COMs object model is designed so that changes in
interfaces don't have cascading effects. In corba, if you change a
base interface and you want to remain binary compatible with old
clients, the dynamic cast function will have to maintain old versions
of epv tables for every interface that inherits from it in the
hierarchy for that object.

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