- From: Furniss, Peter <Peter.Furniss@choreology.com>
- Date: Thu, 7 Oct 2004 12:30:41 +0100
- To: "Gary Brown" <gary@enigmatec.net>, <public-ws-chor@w3.org>
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