Upayavira wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole environment abstraction completly and
make Cocoon a web framework. Period.
Agree, but as people (you included) had valid reasons for not going that
far in 2.2, I suggest something less radical this time, as I want to get
rid of the problem of calling servlets from within Cocoon already in 2.2.
I am starting to change my mind about this in regard to 2.2. 2.2 is
changing as a concept. It was previously just a small step up from 2.1,
in which case a significant change in interface would not have been
appropriate. However, particularly the maven build, but also a lot of
the other stuff that is going on, is leading to some quite substantial
improvements.
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
More particularly Daniel's proposals to do with using
servlet interfaces for block controllers would make it possible to
implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this
framework.
That is the goal :)
If this is the case, then it would seem timely to improve these
interfaces now, as 2.2 given the greater flexibility could become _the_
future Cocoon, and we may miss the boat if we don't make this change now.
Yes, I feel some urgency. With enough focus and dedication on
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
regain its momentum. Focusing on 2.2 seem more like losing valuable time
for me.
But that is IMHO, if enough people are prepared to make a 2.2 happen, I
will of course join in that work.
Now, we have currently two other environments: cli and portlets. A
portlet is a web application, so there won't be any problem. And for
the CLI we can come up with some kind of HttpClient that internally
starts Jetty etc.
Yes. For CLI an alternative is to have a minimal servlet container as
part of the CLI. Maybe its possible to use Jetty in that way without
needing to go over a socket?
Why a servlet container? Or do you mean simple implementation of the
servlet interfaces? That would be what we would need. Something to set
up request and response and call the servlet's service() method.
I mean a simple implementation of the servlet interfaces as you suggest.
I haven't studied the CLI implementation in any detail, what is your
opinion about letting it work on the servlet interfaces rather than at
the Processor level. What consequences will it have?
/Daniel
