RE: CORBA question

[Philip Dawes <PhilipD parallax co uk>]

> -----Original Message-----
> From: Felix Bellaby [mailto:felix@pooh.u-net.com]
> Sent: 09 December 1998 01:43
> To: sopwith@redhat.com
> Subject: Re: CORBA question
> 
> 
> Elliot Lee writes:
>  > On Tue, 8 Dec 1998 16:25:53 +0000 (GMT), Felix Bellaby 
> <felix@pooh.u-net.com>
>  > wrote:
>  > 
>  > >There are alternative approaches based on goad server_ids but 
>  > >AFAIK there is a one to one mapping from repo_ids to server_ids.
>  > 
>  > Not once someone installs a second help browser on your system ;-)
>  > 
>  > The repository ID identifies the interface that the server 
> supports. The GOAD
>  > server ID uniquely identifies the implementation. You can 
> have more than one
>  > program that implements an interface.
>  > 
>  > A good example is all the panel applets, which implement the same
>  > IDL:GNOME/Applet:1.0 interface, but have different GOAD ID's.
> 
> I thought that was the case really (: but I still do not understand
> why we are taking this approach.
> 
> You do not have more than one set of code that implements a widget 
> in gtk or a class in C++. What you have instead is object 
> inheritance. 
> 

What you have is *class* inheritance. You might have one set of code that
implements a particular widget class, but you can have lots of 'objects'
that provide that interface.


> Is there a good reason why we can not use IDL object inheritance 
> within the interface repository to handle the cases where we have 
> multiple servers implementing the same interface ?
> 
> e.g.:
> 
> module GNOME 
> {
>   interface applet
>   {
>    ...
> 
>   };
> 
>   interface fish_applet : applet {};
>   interface bussign_applet : applet {};
> }
> 
> This enables you to get access to a given server like this:
> 
> CORBA_OBject applet = 
>     goad_server_activate_with_repo_id (NULL, 
> "IDL:GNOME/fish_applet:1.0", 0);
> 
> Rather than using this:
> 
> GoadServer sinfo = { 0, "IDL:GNOME/applet:1.0", "fish_applet", NULL };
> CORBA_OBject applet = 
>     goad_server_activate (sinfo, 0);
> 
> I think the object inheritance approach is better becuase it uses a
> CORBA core feature (the interface repository) to access the servers
> rather than using an API which is completely outside CORBA (the
> server_id). It is every bit as flexible and more distributed.
> 
> What disadvantages is it supposed to have ?
> 


Here's the problems:

1) 'Activate' is not the same as 'create'. Semantically, when you 'activate'
a corba object you are just making it ready to use - the idea is that these
objects are 'always' there, but their implementations can be activated and
deactivated. These implementations can even change over time, but the object
is still semantically the same object.

I think what you are trying to say with your api is 'create me an object
which has this repoid as it's most derived interface', and you want to
inforce the notion that there can only be one implementation of each 'most
derived' interface, not each interface.


2) Given that the corba model does not involve creation semantics (this must
be implemented explicitly by objects themselves - i.e. factories), by
binding object activation to the interface what you would effectively be
doing is creating a 1:1 mapping between interface and *object* - this isn't
the case in any OO system. 


Actually what you are really describing here is a concept of 'Class', rather
than interface. A class (as I'm sure you know) is the implementation of an
interface (or set of interfaces), and an object is an instantiation of a
class. An interface is simply a useage contract which an object adheres to -
i.e. 'I do these things'. There can be many objects which do these things,
and many classes which implement them. C++ and other object languages blurr
this distinction by having interfaces as an implicit concept which is
tightly bound to the class which implements it. Note that Java supports the
notion of interface directly (i.e. no implementation involved), and classes
explicitly have to implement them.

Incidently, creation semantics and classes is what COM provides - you have a
load of interfaces, and then the a 'Co-Class' which implements those
interfaces. The client can the 'co-create' a new instance of a class. 

The CORBA model doesn't provide explicit support for creation semantics and
the notion of classes, only activation semantics and the notion of
interfaces. How you implement these interfaces and lifecycles is up to you,
but by inforcing a 1:1 mapping between interface and object you are breaking
the corba spec.

Just as an addition, even if we did decide to break the spec in this way, if
I've understood your scheme correctly we'd need to have a default
implementation for each interface - how would that work with interfaces like
'widget' and 'applet'?

Hope this makes sense,

Cheers,

Phil.