cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 13:37:34 GMT
Daniel Fagerstrom wrote:
> 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.

Question is is there an interim "thing" that we can release before whole
OSGi is implemented? We were talking about an RC when Maven build was
done, but we seem to be moving away from that.

Gradual steps, release often is good. Making life harder for future
exciting developments by releasing too early isn't good.

>>  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 :)

Yup, and I like it.

>> 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.

Well, define 2.2 :-)

I presume you mean releasing a Maven based Cocoon without a ready blocks
system would loose valuable momentum.

> But that is IMHO, if enough people are prepared to make a 2.2 happen, I
> will of course join in that work.

Again - define what 2.2 is. At the moment, these are just numbers. We
should be taking about whether we are going to release feature sets, not
numbers.

>>>> 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?

Wouldn't be too hard. It builds its own Request, Response and
Environment, and a Cocoon object to use. Moving it across shouldn't be
too hard (although the CLI could do with a _serious_ rewriting, but
that's for other reasons).

Regards, Upayavira





Mime
View raw message