> > - If it was possible to avoid code duplication for as many components as
> > possible it would be great ;) Fixes / improvements are really hard to
merge
> > otherwise. Since I think the main point of disagreement is the servlet
> > engine core, that should be doable.
>
> That's what I think too - if you are referring to webdav, all I did was
> make it work with tomcat3.
Catalina's DefaultServlet and WebdavServlet are only tied to Catalina's
extended ServletContext. Basically, we're doing all resource access
operations through it, in an abstracted way; however, since there are no
write / dir browse operations in the servlet context yet, we had to extend
it.
I think the Resources stuff are at the right spot in the architecture :
hidden behind the ServletContext, so that the data they abstract is
availible to any servlet.
> I don't think that's wrong - it is great code and it should be portable.
That's not wrong (that's right, actually ;)), but I don't see how it can be
portable except by either :
- Using java.io.File, and don't care about abstraction.
- Using an abstraction layer which is put underneath the servlet. That's
exactly what I'm doing in Slide, actually, and it's portable (JDK 1.1 /
Servlet 2.2) and everything.
> You are the main author and you can of course decide if you want it to be
> used only with catalina or if other servlet containers are allowed to use
> it.
Lol. How can I do that with the APL ?? Hey Craig, let's write a Catalina
Public Licence to address that ;)
Seriously, I encourage anyone to reuse the code, but I just wanted to expose
here the few reasons why that particular component is "tied" to Catalina.
Some other people have also expressed that it wasn't a good idea to add such
a big chunk of code into the 3.x codebase.
> ( of course, I'll have to track whatever happens in the main repositroy
> and keep the ported webdav up to date, or you may want to take some of the
> changes and make it an independent module, as it should be IMHO. )
>
> I don't know if "people don't want this kind of features in 3.x " - so
> I'll remove it from the main 3.x tree and make it a revolution ( move it
> to proposals), so nobody can complain about it and anyone who's
> interested can use it. From my point of view it's great code and it would
> be great to have it available in 3.3.
I guess we could vote on the subject, but if we leave it in, we'd have to
provide support / fixes for that within the 3.x branch, which could be a
problem since nobody's actually taking care of that right now (except
Craig).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
