You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@vafer.org> on 2004/03/29 15:30:41 UTC
java continuations
Dear friends and folks,
as already announce on the PMC list we now
have another flow implementation for java!
Stephan completed my proof-of-concept and
replaced the Brakes stuff by an own
implementation. So we are now fully in
ASL land.
We would like to commit this implementation
as a block. It comes with examples so anyone
can give it a try.
The block is currently named "jflow". But
we also talked about "javaflow". So what
would you guys prefer:
[ ] jflow
[ ] javaflow
[ ] ________
[ ] nah... put it somewhere else
cheers
--
Torsten
Re: java continuations
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 29 mars 04, à 15:30, Torsten Curdt a écrit :
> ...as already announce on the PMC list we now
> have another flow implementation for java!
whooo-hooh, congrats!!!
> ...So what
> would you guys prefer:
>
> [ ] jflow
> [X ] javaflow
But unfortunately (Google sez) both seem to be used already.
I think jflow or javaflow are ok for a Cocoon block name, but it this
goes further (and I hope it will) you might need another name.
-Bertrand
Re: java continuations
Posted by Stephan Michels <st...@apache.org>.
Am Mo, den 29.03.2004 schrieb Sylvain Wallez um 19:05:
> jflow isn't good as it doesn't allow the distinction between JS and Java.
Okay, seems that we agree on "javaflow".
> Now what should go in that block: the _flow_ implementations, or the
> class enhancer? I would stay that only the flow implementation has its
> place inside Cocoon's CVS. But finding a more suitable place for the
> enhancer (BCEL, jakarta-commons, codehaus?) may take some time, and we
> may temporarily host in in the javaflow block.
Yes, we have already talked with james strachan. And he seems to be
interested too. But for the first time I would start within Cocoon.
> Now about whether Cocoon should have two flow implementations, I think
> that this is a very special case where it makes sense, as it touches the
> programming language area, where Cocoon brings nothing new to the
> picture (except of course continuations), and therefore has to consider
> people's habits. Convincing people that flow is a good thing is rather
> easy (considering the number of Wows!), but selling a particular
> programming language (as opposed to some XML dialect) is sometimes
> difficult. Some people will love JS and be frightened by Java, and some
> others won't consider writing code using a language other than Java.
>
> That's why I think both implementations have their place in Cocoon.
>
> Ah, and would it be possible to use the class enhancer to enable
> continuations in a compiled (as in ".class") JS script? This may help us
> solving the current Rhino issues.
I think all java classes are capsulated in wrapper classes, and if these
classes suppport the continuation, then it should work.
Okay, then I start to commit the block.
Stephan.
Re: java continuations
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 30 mars 04, à 10:45, Sylvain Wallez a écrit :
> ..."JS compiler" yes, but "our own" certainly not!! Rhino can produce
> regular class files from JS source code, and I was wondering it it
> would be possible to instrument these Rhino-generated classes with the
> continuation classloader...
Ok, got it.
You mentioned that this could solve Rhino issues, I assume these are
technical issues, not the community/licensing ones?
-Bertrand, being curious today ;-)
Re: java continuations
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
>
> Le 29 mars 04, à 19:05, Sylvain Wallez a écrit :
<snip/>
>> ...Ah, and would it be possible to use the class enhancer to enable
>> continuations in a compiled (as in ".class") JS script? This may help
>> us solving the current Rhino issues...
>
>
> This sounds interesting but I don't get it, can you elaborate about
> the "compiled JS" part?
> Do you mean using our own JS compiler? At runtime?
"JS compiler" yes, but "our own" certainly not!! Rhino can produce
regular class files from JS source code, and I was wondering it it would
be possible to instrument these Rhino-generated classes with the
continuation classloader.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 29 mars 04, à 19:05, Sylvain Wallez a écrit :
> ...Now what should go in that block: the _flow_ implementations, or
> the class enhancer? I would stay that only the flow implementation has
> its place inside Cocoon's CVS. But finding a more suitable place for
> the enhancer (BCEL, jakarta-commons, codehaus?) may take some time,
> and we may temporarily host in in the javaflow block...
+1, the base continuations stuff certainly deserves a separate
distribution. But there's no hurry, it can live here for a while.
> ...Some people will love JS and be frightened by Java, and some others
> won't consider writing code using a language other than Java...
Agreed, but I still think the "official" focus should be on *one* Flow
language.
It seems like we all agree to declare the java Flow experimental for
now, but we must be careful about the user's perception (which is
reality ;-), by putting big EXPERIMENTAL STUFF signs where needed.
> ...Ah, and would it be possible to use the class enhancer to enable
> continuations in a compiled (as in ".class") JS script? This may help
> us solving the current Rhino issues...
This sounds interesting but I don't get it, can you elaborate about the
"compiled JS" part?
Do you mean using our own JS compiler? At runtime?
-Bertrand
Re: java continuations
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Curdt wrote:
> Dear friends and folks,
>
> as already announce on the PMC list we now have another flow
> implementation for java!
>
> Stephan completed my proof-of-concept and replaced the Brakes stuff by
> an own implementation. So we are now fully in ASL land.
Yeah! You're kings guys!
> We would like to commit this implementation as a block. It comes with
> examples so anyone can give it a try.
>
> The block is currently named "jflow". But we also talked about
> "javaflow". So what would you guys prefer:
>
> [ ] jflow
> [X] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
jflow isn't good as it doesn't allow the distinction between JS and Java.
Now what should go in that block: the _flow_ implementations, or the
class enhancer? I would stay that only the flow implementation has its
place inside Cocoon's CVS. But finding a more suitable place for the
enhancer (BCEL, jakarta-commons, codehaus?) may take some time, and we
may temporarily host in in the javaflow block.
Now about whether Cocoon should have two flow implementations, I think
that this is a very special case where it makes sense, as it touches the
programming language area, where Cocoon brings nothing new to the
picture (except of course continuations), and therefore has to consider
people's habits. Convincing people that flow is a good thing is rather
easy (considering the number of Wows!), but selling a particular
programming language (as opposed to some XML dialect) is sometimes
difficult. Some people will love JS and be frightened by Java, and some
others won't consider writing code using a language other than Java.
That's why I think both implementations have their place in Cocoon.
Ah, and would it be possible to use the class enhancer to enable
continuations in a compiled (as in ".class") JS script? This may help us
solving the current Rhino issues.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> On 29.03.2004 21:02, Sylvain Wallez wrote:
>
>>> If the vote majority will shift to another name instead of javaflow
>>> we can still move it around. If Carsten does not insist on his -1
>>> including a removal I would let it at the place where it is at the
>>> moment.
>>
>>
>> Uh? If it's a majority vote, then can Carsten's -1 be considered as a
>> veto?
>
>
> In which cases our votes are veto-able?
http://incubator.apache.org/learn/voting.html
I guess this falls under "code modification" ?
>
> Joerg
Tony
Re: java continuations
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.03.2004 21:02, Sylvain Wallez wrote:
>> If the vote majority will shift to another
>> name instead of javaflow we can still move it around. If Carsten does
>> not insist on his -1 including a removal I would let it at the place
>> where it is at the moment.
>
> Uh? If it's a majority vote, then can Carsten's -1 be considered as a veto?
In which cases our votes are veto-able?
Joerg
Re: java continuations
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 29.03.2004 20:39, Stephan Michels wrote:
>
>>> Hmm, 4h for a vote was a bit short, wasn't it? So just for the
>>> records: I'm with Antonio and so like JFlow vs. JSFlow.
>>
>>
>> I know, I know, sorry about that, guys. I was very impatient. I could
>> revert it if you want.
>
>
> Not because of my comment. If the vote majority will shift to another
> name instead of javaflow we can still move it around. If Carsten does
> not insist on his -1 including a removal I would let it at the place
> where it is at the moment.
Uh? If it's a majority vote, then can Carsten's -1 be considered as a veto?
I also agree that 4 hours is a bit short, but also understand Stephan's
impatience ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 29.03.2004 20:39, Stephan Michels wrote:
>
>>>Hmm, 4h for a vote was a bit short, wasn't it? So just for the records:
>>>I'm with Antonio and so like JFlow vs. JSFlow.
>>
>>
>> I know, I know, sorry about that, guys. I was very impatient. I could
>> revert it if you want.
>
> Not because of my comment. If the vote majority will shift to another
> name instead of javaflow we can still move it around. If Carsten does
> not insist on his -1 including a removal I would let it at the place
> where it is at the moment.
I am with Carsten too. Note he is just against the right place to put it.
That is all. Think in newbies.....
You will see a big neon: "JavaFlow" inside blocks and none telling you
"JavascriptFlow". Also BTW, If one will be called JavaFlow, then the over
must be called using the ugly large name: "Javascriptflow".
This is why I prefer: JFlow and JSFlow.
Best Regards,
Antonio Gallardo
Re: java continuations
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.03.2004 20:39, Stephan Michels wrote:
>>Hmm, 4h for a vote was a bit short, wasn't it? So just for the records:
>>I'm with Antonio and so like JFlow vs. JSFlow.
>
>
> I know, I know, sorry about that, guys. I was very impatient. I could
> revert it if you want.
Not because of my comment. If the vote majority will shift to another
name instead of javaflow we can still move it around. If Carsten does
not insist on his -1 including a removal I would let it at the place
where it is at the moment.
Joerg
Re: java continuations
Posted by Stephan Michels <st...@apache.org>.
Am Mo, den 29.03.2004 schrieb Joerg Heinicke um 20:32:
> On 29.03.2004 15:30, Torsten Curdt wrote:
>
> > [x] jflow
> > [ ] javaflow
> > [ ] ________
> > [ ] nah... put it somewhere else
>
> Hmm, 4h for a vote was a bit short, wasn't it? So just for the records:
> I'm with Antonio and so like JFlow vs. JSFlow.
I know, I know, sorry about that, guys. I was very impatient. I could
revert it if you want.
Stephan.
Re: java continuations
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.03.2004 15:30, Torsten Curdt wrote:
> [x] jflow
> [ ] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
Hmm, 4h for a vote was a bit short, wasn't it? So just for the records:
I'm with Antonio and so like JFlow vs. JSFlow.
Joerg
Commited was Re: java continuations
Posted by Stephan Michels <st...@apache.org>.
Am Mo, den 29.03.2004 schrieb Torsten Curdt um 15:30:
> Dear friends and folks,
>
> as already announce on the PMC list we now
> have another flow implementation for java!
>
> Stephan completed my proof-of-concept and
> replaced the Brakes stuff by an own
> implementation. So we are now fully in
> ASL land.
Okay, the implementation is now in the CVS, and is ready to get
tested.
I should try to explain how is works. The java flow
use the bytecode pass3b verifier of BCEL to analyse the
the control flow of the bytecode sequence, and to analyse the
content of the current frame for every instruction.
Means, I know at every instruction which objects are in
the stack and in the local variables.
Next step is to add intercepting code for every method invocation,
which tests if the current invoction should be captured to continue
the invocation next time. To capure the invcation the complete
frame will be stored in the continuation.
To restore the invocation the frame will be restored and jumps
to the last invocation, and this will be done for every stack trace
element.
The implementation is rather simple. The core consists of 3 classes:
ContinuationClassLoader, Continuation and ContiationStack.
The ContinuationClassLoader adds the intercepting code to the classes,
the Continuation stores the information about the current running
continuation, and ContinuationStack stores the capured stack.
Re: java continuations
Posted by Steven Noels <st...@outerthought.org>.
On 29 Mar 2004, at 15:33, Upayavira wrote:
> JFlow could be JavaScript. Only JavaFlow gets it right.
or we should start making the distinction between JSFLow and JavaFlow.
I'm sure we will in the future. :-)
Anyway, here my +1 for a javaflow block.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: java continuations
Posted by Upayavira <uv...@upaya.co.uk>.
Torsten Curdt wrote:
> Dear friends and folks,
>
> as already announce on the PMC list we now
> have another flow implementation for java!
>
> Stephan completed my proof-of-concept and
> replaced the Brakes stuff by an own
> implementation. So we are now fully in
> ASL land.
>
> We would like to commit this implementation
> as a block. It comes with examples so anyone
> can give it a try.
>
> The block is currently named "jflow". But
> we also talked about "javaflow". So what
> would you guys prefer:
>
> [ ] jflow
> [X] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
JFlow could be JavaScript. Only JavaFlow gets it right.
Upayavira
Re: java continuations
Posted by Marc Portier <mp...@outerthought.org>.
Torsten Curdt wrote:
> Dear friends and folks,
>
> as already announce on the PMC list we now
> have another flow implementation for java!
>
> Stephan completed my proof-of-concept and
> replaced the Brakes stuff by an own
> implementation. So we are now fully in
> ASL land.
>
> We would like to commit this implementation
> as a block. It comes with examples so anyone
> can give it a try.
>
> The block is currently named "jflow". But
> we also talked about "javaflow". So what
> would you guys prefer:
>
> [ ] jflow
> [ ] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
>
+1 javaflow
congrats on this achievement and big thx
I find today a 'block' the correct flexibility for plugin' in and out
anything that is optional to cocoon
(nice unit contaiment with self explaining xpatch files that serve as
runnable documentation on how to install it in your own project etc etc)
the scratchpad block is IMHO too much cluttering together a lot of other
things
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: java continuations
Posted by Ugo Cei <u....@cbim.it>.
Torsten Curdt wrote:
> as already announce on the PMC list we now
> have another flow implementation for java!
Great!
> [ ] jflow
> [X] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
Ugo
Re: java continuations
Posted by Christopher Oliver <re...@verizon.net>.
Torsten Curdt wrote:
> Dear friends and folks,
>
> as already announce on the PMC list we now
> have another flow implementation for java!
>
> Stephan completed my proof-of-concept and
> replaced the Brakes stuff by an own
> implementation. So we are now fully in
> ASL land.
Cool.
>
> We would like to commit this implementation
> as a block. It comes with examples so anyone
> can give it a try.
>
Please do.
> The block is currently named "jflow". But
> we also talked about "javaflow". So what
> would you guys prefer:
>
> [ ] jflow
> [ ] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
>
> cheers
> --
> Torsten
>
javaflow seems fine. +1.
BTW, I think it's important to give people a chance to review the code
and experiment with a Java-based flow controller before we jump to
conclusions about its pros and cons versus the JS-based one.
Regards,
Chris
Re: java continuations
Posted by Antonio Gallardo <ag...@agssa.net>.
Torsten Curdt dijo:
> The block is currently named "jflow". But
> we also talked about "javaflow". So what
> would you guys prefer:
>
> [X] jflow
> [ ] javaflow
> [ ] ________
> [ ] nah... put it somewhere else
jflow is shorter and jsflow can be used for javascript flow. To me as far
as both flow engines (J & JS) show the same API, will be fine to allow
user write the flow in what language they like.... or maybe both. Who
knows? :-D
The problem of a JFlow block "tag" is that it will suggest it contains the
ONLY one implemented Flow Engine. Then will be a good idea to move the
JSFlow out of the Cocoon core. I think the Cocoon core need to be a total
minimum.... Think in people that will only want the JFlow and don't will
use the JSFlow at all.
BTW, I tought Geoff comment about "inheration" in JavaFlow will work and
how it can be benefical in flow.
Best Regards,
Antonio Gallardo
RE: java continuations
Posted by Stephan Michels <st...@apache.org>.
Am Mo, den 29.03.2004 schrieb Carsten Ziegeler um 16:18:
> 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.
IMHO, making the java impl. optional by using a block, should be enough
to send the right signal that the javascript impl. is the main flow
impl.
Stephan.
Re: java continuations
Posted by Tony Collen <co...@umn.edu>.
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
Re: java continuations
Posted by Tony Collen <co...@umn.edu>.
Carsten Ziegeler wrote:
<snip>
> 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.
I've been disconnected for a couple months, when was it decided that "we only want to have one flow
implementation" ?
Additionally, I can't see how it would be confusing if we put it in a block, mark it unstable and
experimental, and put a note stating clearly so, since that's precisely what it is.
> 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.
IMO the best way to evaluate it and see if it's worthwhile is exactly by putting it in our CVS, so I
can't see any problem housing it in the scratchpad. If it becomes strong enough on its own to
become a separate project, then I would not have any qualms about wanting to move the Java
continuations stuff to SF or a separate project housing place.
>
> Carsten
>
Tony
Re: java continuations
Posted by Torsten Curdt <tc...@vafer.org>.
> You have different pros and cons about both implementations. Some users do not
> want to use javascrpt because of it's interpreted nature and some political
> issues (you cannot make your work closed source if you want to sell it).
>
> Java needs to be compiled, the container restarted for each change,
> but the
Not if we integrate the CompilingClassloader as it is on the TODO list.
But we need that eclipse license issue solved first!
> development cycle could shorten when using an advanced java ide (like eclipse)
> - so you do not make such great number if stupid typos you cannot predict. It
> could be faster than javascript and more attractive to commercial vendors.
>
> Even though commercial issues are the last thing that matters here on this
> list it is something that should not be forgotten as if the commerce gets
> interest in cocoon it could provide additional resources for the project.
Who knows :)
cheers
--
Torsten
Re: business questions on opensource lists (was Re: java continuations)
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremias Maerki wrote:
>That was over at krysalis.org. He closed it a few weeks ago because there was not enough traffic.
>
>
... which explains why I couldn't find it :-/
Maybe this list had a too broad scope or not enough visibility. But at
the same time, I don't think a business@cocoon.apache.org is part of the
ASF charter.
>On 30.03.2004 19:05:01 Sylvain Wallez wrote:
>
>
>>Nicola Ken long ago started a list about opensource-related business, but I don't remember its address.
>>
>>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: business questions on opensource lists (was Re: java continuations)
Posted by Jeremias Maerki <de...@greenmail.ch>.
That was over at krysalis.org. He closed it a few weeks ago because
there was not enough traffic.
On 30.03.2004 19:05:01 Sylvain Wallez wrote:
> Nicola Ken long ago started a list about opensource-related business,
> but I don't remember its address.
Jeremias Maerki
business questions on opensource lists (was Re: java continuations)
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
>>>Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets
>>>interest in cocoon it could provide additional resources for the project.
>>>
>>>
>>You're wrong, mate! Apache is a mix of personal and business interests, and a lot of people around there are making a living with Cocoon. So Cocoon features that help it to be adopted by more customers are most than welcome ;-)
>>
>
> just got this impression after asking 2 strictly commercial question on users group and got something like: buzz off, figure it out yourself we're open sourcing here.
>
>
Ah yes, that's true that we don't directly discuss business here, but
I'm surprised that people were pissed because of this kind of question.
I guess most of the people doing their living with Cocoon are on this
list, but it's also not really the place for business discussions.
Nicola Ken long ago started a list about opensource-related business,
but I don't remember its address.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: java continuations
Posted by Leszek Gawron <lg...@mobilebox.pl>.
> >Even though commercial issues are the last thing that matters here on this
> list it is something that should not be forgotten as if the commerce gets
> interest in cocoon it could provide additional resources for the project.
> >
> >
>
> You're wrong, mate! Apache is a mix of personal and business interests,
> and a lot of people around there are making a living with Cocoon. So
> Cocoon features that help it to be adopted by more customers are most
> than welcome ;-)
>
I just got this impression after asking 2 strictly commercial question on
users group and got something like: buzz off, figure it out yourself we're
open sourcing here.
Maybe I had the wrong impression.
Leszek Gawron
Re: java continuations
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
<snip/>
>Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets interest in cocoon it could provide additional resources for the project.
>
>
You're wrong, mate! Apache is a mix of personal and business interests,
and a lot of people around there are making a living with Cocoon. So
Cocoon features that help it to be adopted by more customers are most
than welcome ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Mar 29, 2004 at 05:11:45PM +0200, Torsten Curdt 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
>
> 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.
>From my point of view it would be good to make one flow implementation adviced
but to state that the second one is as well supported.
You have different pros and cons about both implementations. Some users do not
want to use javascrpt because of it's interpreted nature and some political
issues (you cannot make your work closed source if you want to sell it).
Java needs to be compiled, the container restarted for each change, but the
development cycle could shorten when using an advanced java ide (like eclipse)
- so you do not make such great number if stupid typos you cannot predict. It
could be faster than javascript and more attractive to commercial vendors.
Even though commercial issues are the last thing that matters here on this
list it is something that should not be forgotten as if the commerce gets
interest in cocoon it could provide additional resources for the project.
my 2c
lg
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: java continuations
Posted by Torsten Curdt <tc...@vafer.org>.
> 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
RE: java continuations
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> Dear friends and folks,
>
> as already announce on the PMC list we now have another flow
> implementation for java!
>
> Stephan completed my proof-of-concept and replaced the Brakes
> stuff by an own implementation. So we are now fully in ASL land.
>
> We would like to commit this implementation as a block. It
> comes with examples so anyone can give it a try.
>
> The block is currently named "jflow". But we also talked
> about "javaflow". So what would you guys prefer:
>
> [ ] jflow
> [ ] javaflow
> [ ] ________
>
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.
Carsten