Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43D7F616.5060909@nada.kth.se>
Date: Wed, 25 Jan 2006 23:05:10 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [RT] The environment abstraction, part II
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I suggested that we should ditch our environment abstraction and replace 
it with the javax.servlet.http set of interfaces, as one step in 
simplifying Cocoon in 
http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2.

The result of the discussion was that there are some "extras" in our 
interfaces compared to the http servlet interfaces that are needed in 
the sitemap, so we would get back incompatibility and maybe other 
problems and it might be much work to accomplish.

Now I would instead suggest that our environment interfaces just extends 
the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends 
HttpServletRequest etc. This should not create any problems with the 
current code base at all AFAICS, and would make it easier to make Cocoon 
cooperate with other systems.

Calling Cocoon from a Servlet environment is currently not a problem as 
we have wrappers, but it gets inconvenient to call servlets from  within 
Cocoon. And the block architecture is Servlet based for making 
integration and development of new controllers easier and the result 
more reusable. As the block protocol requires the sitemap to call back 
the block architecture it would be an advantage if we used the servlet 
set of interfaces.

Also for being able to use the CLI with blocks it need to be able to 
call the block architecture, and here it would also be an advantage if 
our environment interfaces extended the servlet ones.

I'd like to implement the above change ASAP, WDYT?

/Daniel