cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 22:16:11 GMT
Upayavira skrev:
> Daniel Fagerstrom wrote:
>> Upayavira wrote:
>> 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.

Sure there are a number possible interim things.

We can release more or less as is, what is lacking is a Maven 
correspondence of the file and a plugin that collect 
and install the configuration snippets in the blocks to the webapp.

We can also release with non OSGi blocks. The blocks are ongoing work, 
the most important thing that lacks is "two level configuration". As 
discussed before the component configuration is part of the block and 
constant, so they need to be parametrized in some way for making them 
user configurable. We have not had much discussion about how to do this yet.

Also the APIs and concepts for blocks need to actually be used for some 
real life examples before we can be convinced that we got it right.

> Gradual steps, release often is good.

Agree, but as it will be the first release from trunk the threshold is 

> Making life harder for future
> exciting developments by releasing too early isn't good.

Exactly, one point i that trunk contains nice mechanisms for 
parameterizing components and sitemaps at a global level and also for 
having foreign component managers within sitemaps. While very usefull 
for the current development style in Cocoon they are not very relevant 
for blocks. For blocks we should avoid global configurations as it is in 
the way for splitting Cocoon in small reusable parts. And also component 
configurations in sitemaps is rather unnecessary when we have component 
configurations on the block level.

So what should we do about introducing things that we know that we will 
want to remove in a later release?


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

You are right, I was referring to the first alternative above, i.e. more 
or less as is.

So the main question is if enough people are motivated to work for 
making that happen. I'm not particularly motivated in working for 
keeping life in the monolithic beast for another minor version series. I 
rather work without releasing for a while and release something that I 
will feel proud to be part of.

Again, if there is a momentum for an "as is" release I will of course 
respect that.

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

It seemed that it hasn't been refactored for a while. Much of the setup 
work will not be needed anymore if it call the rest of Cocoon at the 
servlet level rather than the processor level.


View raw message