RE: CORBA question

[Felix Bellaby <felix pooh u-net com>]

Philip Dawes writes:
 > > 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 ?
 > >
 > > 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.

I am not trying to impose a model for creating objects on CORBA.
Goad is an existing part of gnome. I am trying to make the model 
that it uses to start goad servers more accessible outside 
libgnorba by integrating it into the arrangement of the interface 
repository. I think the goad approach has sufficient merits within
its field of operation to make it useful to a wider audience.

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

CORBA does not have constructors but the concept of a void 
constructor still makes sense by analogy. Goad essential
acts a constructor on a interface which takes a single argument:
the server_id. Interface repository binding can only provide a 
void constructor (but is equivalent when there is a 1:1 from
server_ids to repo_ids). These are NOT solutions to the general 
problem of object reference creation or retrieval in CORBA.

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

My intention was to discuss interfaces rather than implementations 
of interfaces. I am contending that distinct goad servers are 
sufficiently different from one another to mean that it would be
USEFUL to interpret them as offering distinct interfaces rather 
than distinct implementations of the same interface. The fish_applet
and diskusage_applet are both things that you can add to the panel
but that is where their similarity ends. We might regret forcing such
dissimilar objects into a single CORBA type.

Where we choose to draw the line between two CORBA types is up to us. 
I am happy to accept whichever division proves the most useful. I 
think the implementation details are essentially irrelevent. However, 
I think that it will generally be useful to distinguish between goad 
servers since users are unlikely to install two goad servers which 
are so similar that using CORBA types to distinguish between them 
is completely useless.

Felix