Il giorno 14/ott/05, alle ore 04:07, David Crossley ha scritto:
Then how about "mature".
I'm afraid a few anti-spam filter might be triggered by that ;-).
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
I don't recall the last discussion. Obviously, if there was an
agreement nothing was done about it.
Currently gump.xml only has status="value". How do the 3 parts get
reflected into that? How does the fact that the api is stable
Ralph Goers wrote:
> Stefano Mazzocchi wrote:
> >Ralph Goers wrote:
> >>Vadim Gritsenko wrote:
> >>>Torsten Curdt wrote:
> >>>
> We only need a few more people using it to find the corner cases.
> >>>
> >>>Stable API != Stable Implementation. If API is stable, you should
> >>>start vote on mar
Reinhard Poetz wrote:
Ralph Goers wrote:
I don't recall the last discussion. Obviously, if there was an
agreement nothing was done about it.
Currently gump.xml only has status="value". How do the 3 parts get
reflected into that? How does the fact that the api is stable but
the implementa
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
I second that. We really need to find a better term than "stable".
One of those discussions hitting us every 3 to 6 months. Anyway, last
time we agreed (for blocks) that we split up stability into three parts:
- api
- imple
Reinhard Poetz wrote:
Ralph Goers wrote:
I second that. We really need to find a better term than "stable".
One of those discussions hitting us every 3 to 6 months. Anyway, last
time we agreed (for blocks) that we split up stability into three parts:
- api
- implementation
- communit
Torsten Curdt wrote:
(NB I hope that I can soon drop Apples in favor of JavaFlow as using
a state machine is a PITA. The missing part is serialization support
for Javaflow. It is itself already serializeable as Torsten showed
me in Amsterdam, but needs some integration work in Cocoon to mak
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a be
Mozilla uses 'frozen'.
I've always used that term to mean that there can't be any more
code changes - such as just before a release.
Well, there definitely going to be code changes to improve the
"JavaInterpreter" (stupid name -> RT!)
But as a user you won't have to change anything in your
(NB I hope that I can soon drop Apples in favor of JavaFlow as
using a state machine is a PITA. The missing part is serialization
support for Javaflow. It is itself already serializeable as
Torsten showed me in Amsterdam, but needs some integration work in
Cocoon to make use of it.)
To
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two
exceptions which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
No external API. A
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the "official" flow implementation, what about
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that
Torsten Curdt wrote:
- it looks like javaflow is still quite unstable
Hey, hey, hey! ;) ...that sounds much worse than it is!
It is still marked unstable - that's true. And compared
to Apples it has a bigger complexity implementation-wise
so of course the risk it might break in certain cond
Reinhard Poetz wrote:
Leszek Gawron wrote:
WDYT? If you don't like it I will do 2). only in my codebase.
I like it. I'm one of the Apples users Sylvain mentioned in his mail.
I've also prototyped nearly the same code as you did :-)
Do you use the spring block or does getSpringContext() refe
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a be
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a better term than "stable
Torsten Curdt wrote:
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two exceptions
which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class
Leszek Gawron wrote:
First time the apple is invoked it is created from scratch. Later on if
continuation is being called the apple object is retrieved from
continuation and apple.process( req, res ) is called again on the same
object. You have to maintain view flow yourself. You do not have to
- it looks like javaflow is still quite unstable
Hey, hey, hey! ;) ...that sounds much worse than it is!
It is still marked unstable - that's true. And compared
to Apples it has a bigger complexity implementation-wise
so of course the risk it might break in certain conditions
is bigger. But a
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did "get" Apples. Can somebody just sort of give a quick
summary of what it's all about, and why
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did "get" Apples. Can somebody just sort of give a
quick summary of what it's all about, and why
On 13.10.2005, at 17:45, Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did "get" Apples. Can somebody just sort of give a
quick summary o
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the "official" flow implementation, what about
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did "get" Apples. Can somebody just sort of give a
quick summary of what it's all about, and why I would want to use it?
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the "official" flow implementation, what about
changing its name? "Ap
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class clazz = Thread.current
28 matches
Mail list logo
