Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <43DE5A7F.9070700@apache.org>
Date: Mon, 30 Jan 2006 19:27:11 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] The environment abstraction, part II
References: <43D7F616.5060909@nada.kth.se> <43DBBC6E.20401@apache.org>
 <43DD1A8C.8070809@apache.org> <43DE4828.1040005@apache.org>
 <43DE5545.6080102@apache.org>
In-Reply-To: <43DE5545.6080102@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

> Now Cocoon is much more than a web framework, as we discussed in the 
> "necessary mutation" thread:
> - a servlet
> - a component container
> - a controller
> - a pipeline engine
> - many blocks built on top of one of the above.
> 
So, if someone asks you what Cocoon is, you say the above? Lock at the
first sentence at cocoon.apache.org: "Apache Cocoon is a web development
framework built around the concepts of separation of concerns and
component-based web development."
Now, you could argue that the docs are out-dated, but I think the point
is that Cocoon has always been marketed as a web framework - and that is
the area we should focus on. Everything else, being it cli or portlet
env or whatever can be built somehow "on top" of the web framework.

> 
> This uses the servlet API, as calling Cocoon from Struts is done using 
> the request dispatcher:
>   request.getRequestDispatcher("/path/to/cocoon").forward(request, response)
> 
Yupp.

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


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/