ClienId generation/storage Issues
lm, Sept 01.


There are 5 main issues: 
1- Do we want a stateless server?
2- where does the generation take place, i.e. client side (megaprogram)
   or server side (megamodule)?
3- where is the value stored?
4- do we need a persistent storage for recovery?
5- how to uniquely define a clientId
and
6. How is it implemented right now?


1. Notion of stateless server:
According to Ron, we should keep our servers stateless for recovery:
in case the server goes down, the client would be able to recover the
state it had before the server went down (right now, the client has no
way to know by itself till which state it has to roll back if the server
goes down).
This is how currently browsers work: cache files and cookies files for
instance are stored at the client side. The server gets such information 
from the client side before processing the client's requests.

=> Question: do we want a stateless server?

Note 1: we have to keep in mind that we already store some information
on the server side (callids, parameters,...). The solution here would be
to generate these in the client where the master copy would always be and
to cache the data in the server, which means some design and code changes.

Note 2: if we do have stateless servers, a client that would go down
would have no way to recover its previous state unless the state has 
been stored persistently at the client side.


2. Generation of the clientIds:

a) Generation at the client side:
- positive points: 1 clientId for all megamodules. It is easier to
handle as the compiler does not have to keep track of which clientId
to pass to which megamodule. Also, this solution means that we deal
with stateless servers as far as the clientId is concerned.
- negative points: the clientId is by definition an identifier of a
specific client for the server and then the server should be the one
to generate it, locally. 

b) Generation at the server side:
- positive points: design consistency as far as the clientId definition
is concerned.
- negative points: 1 clientId per megamodule and not per client; if 12 
megamodules called by the same client, the client is dealing with 12
clientIds. What about if we transfer data directly between megamodules,
data outputed from invoke in megamodule m1 for clientId11 has to be given
as input to invoke of megamodule m2 for clientId12...

3. Storage:
Generation and Storage can occur at different locations, event though it
is logical that the entities generating the clientId detain a master
copy of it. How do we handle it?

4. Persistent storage:
Is it absolutely needed for recovery?
Posponed discussion, as for any recovery issue.

5. Uniquely defined clientIds:
hostname:process_id implies system calls. i.e. platform dependance
Also implies that once a client qoes down, it won't have the same id
when it comes up again (but that is required by the definition of
uniqueness itself...)

Note: client ids can be easier to handle if generated by the server,
but then the client must keep track of the relation 
clientId-mm_reference for each mm


6. How is it implemented right now?
- ClientId generated in the client
- as a string: hostname:processId
- code generated by the compiler in the client so that the clientid
string is composed at run time