ROI, ORG, [pem 06/03]

[Peter Mueller]

Hi,

I want to present two points.

1. Who is absolutely interested in designing ROI for Moose? (I mean, who is
   not able to live without it :-) This is the first attempt to create a smaller
   group. Maybe we can setup a smaller alias list. And others are not bombed
   with mails.

2. I've thinked about a problem, which - in my opinion - covers the area of
   the compiler designers (see below)

Ad 1.

I want to form a smaller group of interested people, to force a useful
specification on ROI (where a 1 is the major number ...). I plan to inform the
whole Moose community periodically each quarter a year. (If this is QUIRKS:
I mean after 3 weeks.) In my opinion we should create smaller groups, where
people talk especially and exactly about one (1) topic, and where mails
referencing to multiple sujects can be avoided. What do you think?

Ad 2.

Last night the following problem (and it's possible solution) came into my
mind. An object is, at least able to have two 'address spaces', namely private
and public. Variables, or 'objects' within the private space are only visible
to the object, whereas objects in the public space are also seen to the outer
world.

Now consider the following object:

class example {
   int i;               // i is private

public:
   int j;               // j is public

   void do_something() {
      i = 1;            // Change object's private state
      j = i + 1;        // Change object's public state
   }
};

Now consider, that 'do_something()' is a service, made available via the
DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
invoke do_something().

What happens?

For the client object, the example must change its private state! But this
must only be seen to the client object! Not to others. On the other hand,
the change to the public state must be seen to all other clients.

We can say, the change of the private state is a local change to the state
seen by a specific client object, whereas a change of the public state is
a global change seen to all possible client objects.

Where are the problems?

The global change leads to a synchronization problem. In each situation we
have to take care to establish a consistent state. (I think, that's where
the compilers must give as much as help as they can!)

The local change makes it necessary to provide a copy of at least the private
members of an object for each client object! (And therefore we need tools, 
which similiar to those nice stub-making tools for RPC.)

Solutions?

Well, to the local change there is an easy solution. Each client, wanting to 
use other objects' methods remotely, will create an appropriate instance of
a server class. This class will inform the remote object, that there is a new
client. This will lead at the remote object to 'fork' (if you will forgive my
UNIXness ;-) a private copy, especially for this new client. The private copy 
consists of 

   1) The private state as it was created on server startup time. (Each time
      a new client occurs, it will see the same private state.)
   2) The public state at this time. (A newly client can see different states
      than previous ones.)

At the client side, this will be done within the constructor of the server class
instance. The destructor call will inform the remote object to discard the
created client's private view.

I suggest the following terms for the - perhaps - following discussion:

connector - This is the object used by a client object to establish a new
            connection to a remote object. The constructor will inform the 
            remote object, that there is a new client, whereas the destructor
            will say, that the client is finished.

shadow    - This is the (remote) object which is actually seen by a client
            object after connection. Within this object only the private 
            (and/or protected (?)) members of the remote object are hold.
            Public members are still shared through the 'real' remote object.
            The shadow is created after a connection request by a connector.

(The connection between client and shadow must provide a merge between the
valid private and public state. Thus, the shadow 'merges' the local view and
the global view.)

Other Problems?

What's about availability and fault tolerance? Reliability? Garbage collection?

Hope, to hear some comments,

Peter