I really value all the work and effort that you all put into this, but I would say:
[X] nah... put it somewhere else
We only want to have one flow implementation (language), which is
Javascript. If we put the Java version as a block in our CVS, it
immediately looks like that if we would have two and more implementations
or even worse, that the JavaScript implementation was a mistake. And then the confusion about "Which one should I use?", "Which
one is better?", "How long is the JavaScript impl. supported?" etc. starts. And I would really like to avoid this.
It's ok for me, to evaluate the Java Continuations and decide later which version to support (with a clear migration path if required),
so I would prefer to put it somewhere else (sf, cocoondev etc.).
If everyone else wants to have it directly in our cocoon cvs then
I would prefer the scratchpad block.
This brings up an interesting idea... I'm not an expert on how the Rhino interpreter works, but wouldn't some sort of abstraction layer that sits between the language we're writing the flow in, and what actually gets run be an option? In the future, if we end up getting Groovy or Jython-based continuations, we wouldn't have to maintain multiple copies of the Flow API, etc.
But like I said, I'm no expert on programming languages so the very design of how it all works could block some sort of abstraction layer from being built. Just a thought.
Carsten
Regards,
Tony
