cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 23:01:51 GMT
Carsten Ziegeler skrev:
> Sylvain Wallez wrote:
>> Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based 
>> implementation of the servlet API, but having the Cocoon CLI launching 
>> an internal Jetty for this really seems wrong to me. Forrest is already 
>> a large beast, now if you say that generating a site requires to start a 
>> servlet engine, many people with run away for something probably less 
>> powerful but much more light.
>>
> Then let them run. No, seriously, we can be all to everyone. This is the
> flexibility syndrom in action. From a user pov, where is the difference
> in starting the current cli and starting a cli which internally fires up
> jetty and uses http? It's transparent - but it makes the implementation
> of Cocoon much easier.

Setting up a HttpServletRequest object and a ServletConfiguration object 
is all that is needed for calling a servlet. It requires not that much code.

...
> Now, if I'm the only one thinking that removing the whole env
> abstraction makes sense, I'll shut up for now.

You are not, but as you also state that you don't want it now it makes 
your position less easy to agree with.

My plan is:

* Let our environment abstraction extend the http servlet set of 
interfaces now, (back compatible and solves the problem at hand).

* Push down the creation of the Environment object one step at a time 
through the call chain (refactorings, will remain back compatible as 
long as we have our interfaces in the object model, when we remove that 
it will create incompatibility).

/Daniel

Mime
View raw message