These somewhat minor changes will allow a greater variety of implementations of the Cocoon flow layer. And this is not only for the technical beauty of it, as there are a number of good reasons why we may want alternate implementations :
- some people (talking about personal experience with some customers) don't want to write their controller in JavaScript. They want it in Java. Although a continuation-enabled Java is not yet available, solutions exist to write this using plain old Java.
Sorry, but it's already been demonstrated that a Java flow implementation is possible without any of these changes.
- some applications (this is Marc's case) must use an existing flow controller and so can't use the JS implementations.
What exactly is "Marc's case"? I read his wiki and I have to admit I don't understand what he's talking about.
Chris
