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
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
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.
Carsten Ziegeler wrote:
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.
A
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
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
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
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 th
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 announce on t
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
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
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 d
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
49 matches
Mail list logo
