I really value all the work and effort that you all put into this, but I would say:
[X] nah... put it somewhere else
Uff... a bit discouraging I have to admit. Actually I hoped noone would pick that option.
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.
Well, for sure we know from our long and winded road to a single form framework that too many options are bad ...but since it implements all the very same interfaces it feels just like a different language. ...like we have different options for xsp.
Since I was one the preachers of less options this might feel a bit awkward but I *do* think a block is the better choice. It's going to be marked as unstable and the javascript flow is in the core. I don't think this will give a wrong perception. But we are never immune to any of those questions as soon as it's available somewhere.
I remember you don't like to have too many blocks in the CVS but going from modular back to monolithic (scratchpad) doesn't help IMO.
The only thing that will help are the "real blocks" ...and I am glad Pier is helping us to finally get this thing rollin'
cheers -- Torsten
