cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Collen <colle...@umn.edu>
Subject Re: java continuations
Date Mon, 29 Mar 2004 16:14:39 GMT
Carsten Ziegeler wrote:

> 
> 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


Mime
View raw message