optional messages (was RE: CDL collision resolution)

Vaguely related to the collision question, and arising from some of the
discussion on Tuesday of the face-to-face (most of this was originally
done last week)



The cases where

   A sends some number of messages X; then A sends one message Y

   A may or may not send message p; A sends message q

(with the decision as to which to send being decided by conditions
at A), are essentially similar. After n occurences of X, another
X is effectively optional - the difference is just that, if there is an
X, the dance stays at the same point, where as after a p, it moves on 
to q. But you can treat them both as X{min,max};Y with min=1, max=* in
the first case, min=0, max=1 in the second.

(recasting "send message" to "interaction" doesn't really change things,
though is important for generality)

It's going to be pretty easy to implement the real receiver (B) in 
reality, so CDL shouldn't require heavy mechanisms. Just recognizable
ones.

There doesn't seem any point in pretending there is some information
available at B which will tell it what is coming next. It's going
to find out when the interaction occurs.

<sequence>
...
   <workunit repeat="true" guard="something at A">
       <interaction operation="X">
   </workunit>
   <interaction operation="Y">
...
</sequence>    

To my surprise, I seem to have omitted the <choice> - I couldn't see a
need for it - the 
workunit keeps repeating until the guard fails, then falls through. If
it were
a single optional message, then just omit repeat="true".

On projecting to the endpoints, that's easy for A

while (somethingHere() ) {
    channelToB.sendX();
}
channelToB.sendY();

It requires a bit more intelligence at B. The projector has
to recognise that the guard condition is no use to it and
create code than is driven by what comes in.

boolean x_looping = true;
while (x_looping) {
    Message incoming = channelFromA.receive();
    switch (incoming.type) {
    case X: processAsX(incoming);
            break;
    case Y: processAsY(incoming);
            x_looping = false;
            break;
    }
}

My argument against pretending there is something at B that
will let it know what is coming is that it won't help the
projection - it HAS to be determined by an incoming message, and
so B must read the message before it finds out what it is.
You could force the distinction down into the 
infrastructure messages/headers.
    
An unpleasantness of that is the B projector has to do a lookahead,
and it might be nicer to have a 1:1 relation between the cdl construct
and what is generated.

Peter


Choreology Anti virus scan completed

Received on Thursday, 7 October 2004 11:31:19 UTC