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
