Has there been any discussion of extracting Java continuations into a
standalone project?
There are a lot of people (judging by web searches... and including me
:-) who would love to use this functionality, but not in the context of
Cocoon.
There has been the discussion to move it over
Title: Message
Has there been any discussion
of extracting Java continuations into a
standaloneproject?
There are a lot of people
(judging by web searches... and including me :-) who would love to use
this functionality, but not in the context of Cocoon.
We'd like to invite everyone who is interested
to join our initiative on codehaus.org. We are
aiming to write and submit a JSR for native java
continuations support inside the JVM.
We are currently looking for people that have
any kind of expertise in the continuations field
or just like
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
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,
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.
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
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
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
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 [EMAIL PROTECTED] is
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
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
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
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
I don't get to see the PMC list. I love the idea of Cocoon supporing Java
Flow!
Ralph
-Original Message-
From: Torsten Curdt [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 5:31 AM
To: [EMAIL PROTECTED]
Subject: java continuations
Dear friends and folks,
as already announce
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
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
? 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
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
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
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
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
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
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
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
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.
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
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
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
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
?
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
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
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,
the efforts and create general
java continuations project until java might get native continuations.
We could also (at least) try to push this a little. But this also
stalled probably due to the lack of time.
Although quite some people contacted me in private on this subject
I thought we (cocoon) decided
Torsten Curdt wrote:
...but java continuations with the compiling classloader sounds
pretty cool to me :)
I agree. I would also like to try out Groovy or Jython... but I do have
fears on diverging too much.
I mean: do you guys think we really got the point where we understand
what we want
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was significantly
Christopher Oliver wrote:
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level),
I recently took a look at joeq (http://joeq.sourceforge.net/) which is a
Java virtual machine written in Java. Included is a reflective Java
interpreter that can run on top of an existing Java virtual machine
(e.g. Sun JRE). It can interpret class files, but can also delegate some
(or all)
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower than
interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was significantly faster than
BeanShell (which is
From: Bertrand Delacretaz
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be
slower than
interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was
On 21 Feb 2004, at 17:48, Reinhard Poetz wrote:
Since Cocoon supports continuations they seem to attract more and more
interest in the web development world ;-)
Which proves Ovidiu's visionary skills. We owe him a great deal because
of this.
/Steven
--
Steven Noels
Reinhard Poetz wrote:
If there is support for Groovy, Pyhton, [or whatever] continuations, I
personally don't care because it doesn't make a real difference
(languages are a matter of taste ...) and I don't think we should spread
our energy over different Flowscript interpreter implementations
From: Gianugo Rabellino
Reinhard Poetz wrote:
If there is support for Groovy, Pyhton, [or whatever]
continuations, I
personally don't care because it doesn't make a real difference
(languages are a matter of taste ...) and I don't think we should
spread our energy over different
From: Gianugo Rabellino
Reinhard Poetz wrote:
If there is support for Groovy, Pyhton, [or whatever]
continuations, I
personally don't care because it doesn't make a real difference
(languages are a matter of taste ...) and I don't think we should
spread our energy over different
On 21 Feb 2004, at 19:24, Gianugo Rabellino wrote:
Well, we actually have to maintain a non-current forked version of
Rhino (even if pretty stable actually), so I'd much rather change my
taste (I quite like Javascript flow actually) if that buys me a more
hassle-free continuation engine.
I'm
On Feb 21, 2004, at 2:47 PM, Steven Noels wrote:
Overall, I sense an interest to opt for ASF packages whenever
possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is
moot.
Umh... continuations in PHP or Jelly. That covers Apache (c) languages
available ;-)
-Brian
Reinhard Poetz dijo:
Since Cocoon supports continuations they seem to attract more and more
interest in the web development world ;-)
This is great! This means Cocoon is the leader in webapp development! :-DD
Anyway, for me only **Java** Flowscript would really make sense because
this would
Stefano Mazzocchi wrote:
Brian McCallister wrote:
Umh... continuations in PHP or Jelly. That covers Apache (c)
languages available ;-)
Correction: as of a few days ago, PHP is no more a project of the ASF :-)
Interesting... I always wondered why PHP is sooo non-Apache...
Neither Apache
48 matches
Mail list logo
