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 into
Title: Message
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.
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 li
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 par
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
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
> >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 busi
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 a
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 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,
>
Bertrand Delacretaz wrote:
Le 29 mars 04, à 19:05, Sylvain Wallez a écrit :
...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 g
he 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
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, c
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.
ly 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 de
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 major
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 Carst
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
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
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 JFl
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 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
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 imp
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
ould 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
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 i
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
ng 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 (s
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 implement
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
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 announ
y 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.
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 Noelshttp
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 implementa
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
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
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 co
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 to
thought
it would be a good idea to share 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
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), b
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 faster
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 fron
Brian McCallister wrote:
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 ;-)
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 wou
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
Steven Noels dijo:
> 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.
+1
Best Regards,
An
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 faster
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 tw
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 di
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
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 whi
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 Noelshttp://out
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
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
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) me
55 matches
Mail list logo