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] Ditching the environment abstraction
Date Tue, 13 Dec 2005 20:13:20 GMT
Sylvain Wallez skrev:
> Daniel Fagerstrom wrote:
> 
>> It seem like we all agree about that the Cocoon core need to be 
>> simplified, although we have different opinions about how to achieve 
>> it. IMO it can be done in steps by refactoring of the trunk.
>>
>> One of the complications with Cocoon is the environment abstraction: 
>> o.a.c.environment.Request, Response, Context etc. They are similar but 
>> not identical to the javax.servlet and javax.servlet.http interfaces, 
>> which means yet another thing to learn for the user. It also means 
>> that it becomes more complicated to use externally developed 
>> components, as these typically implement the servlet family of 
>> interfaces. Furthermore it leads to a more complicated setup process 
>> of Cocoon.
>>
>> So, do we need this extra layer of abstraction?
> 
> 
> Yesterday evening, we had a discussion with some Struts people, and 
> interestingly enough, they wanted to know more about how we abstracted 
> the environment to define an abstraction layer in jakarta commons so 
> that people can develop their webapp modules and deploy them 
> transparently as portlets or servlets by using the proper implementation 
> of the abstraction.

The servlet set of apis is allready an abstraction, we have due to 
historical circumstances another abstraction of the same concepts. To me 
the abstractions look fairly similar, except for the Cocoon aditions 
that have been mentioned. What am I missing more specifically?

So what is it that the struts people are looking for that needs a new 
abstraction?

> So my opinion about ditching our abstraction is that, as we say in 
> France, it is urgent to wait. Along with the backwards compatibility 
> problems that ditching the abstraction in 2.2 may lead to,

We could have compablity wrapper. Question is do we want to simplify or not?

> we should see 
> if that common abstraction comes to life and then consider using it.

Ok, I start consider joining the rewrite from scracth camp ;)

/Daniel

Mime
View raw message