Sylvain Wallez wrote: > Daniel Fagerstrom wrote: >> Often you are going to need the servlet configuration and/or context >> and then you are back on the Servlet interface again. OTH, having a >> Servlet as a managed component is slightly complicated as one need to >> keep track on both its life cycle as a managed component and as a >> servlet. I guess we will see which way that is best to go when you >> have implemented a little bit more. > > IMO that should be servlets, which allow for many other things (and not > only Cocoon) to be integrated in a container. Being able to manage > servlets means we're able to manage anything and can also benefit > from/share with other people's work in this domain. > Hmm, not sure if this is necessary. Imho it should not be the concern of Cocoon to manage other servlets. So if you want to integrate something else which is a servlet, you can use the request dispatcher and leave the rest to the servlet container.
My idea with the processor interface was to say that Cocoon provides you usable *components*. You can just lookup these components and use them which is in the end easier than using servlets - now the difference is very subtle I agree. But it might be that we need an interface which differs in some aspects to the servlet later on. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
