OTS — Activity service Issue: Behaviour of get_coordinator()

The following section is taken from the Activity srevice specification
orbos/2000-06-19.

P51: "It is not strictly necessary for an implementation of the Activity
Service to create an ActivityCoordinator prior to distributing a context
between execution
environments in which it was begun. Each Activity may be managed by at most
one ActivityCoordinator."
The description of Current::get_coordinator() is as follows:
"Returns a reference to the current Activity?s ActivityCoordinator. This
may be nil if a coordinator has yet to be created."

I believe that the act of trying to obtain the ActivityCoordinator should
cause it to be created if it doesn't exist already.
For example, it should be reasonable (on a server at least) to code:

CosActivity::Current_ptr cur;
CosActivity::ActivityCooridinator_ptr coord1, coord2;
...
curt->begin();
coord1 = cur->get_coordinator();
cur->begin();
coord2 = cur->get_coordinator();
coord2->is_same_activity(coord1); // This better be false! It shouldn't
blow up, either.
cur->complete();
cur->complete();

Thus, I believe get_coordinator() should never return nil.

As a second part of this issue some execution environments, for example a
lightweight client, may wish to restrict access to the Activity service
through the Current interface only. Further, some environments may wish to
limit restrict access to the Activity service to a subset of the Current
function, providing little more than the ability to begin and end an
Activity context and explicitly preventing the ability to register Actions
from the environment. For example, a client environment may not have the
capability to service inbound signals for Actions and so may not want to
allow local Action implementations to be registered. Another example is a
where recoverability of the Activity is required but a particular client
environment cannot provide this quality of service. So, I suggest that at
least the Current::get_coordinator() and add_action()/add_actions() methods
should provide an exception that can be thrown by an implementation in an
environment where use of the ActivityCoordinator or Action interfaces is
not intended. In no case would it be desirable for these methods simply to
return nil.

see above