Greg Wilkins wrote:
My limited understanding of WebDAV is that the protocol is pretty tivial - but supporting good configuration control is somewhat harder on the server storage side of things.
Having implemented a Class 2 WebDAV server module for Apache, I'd like to suggest that the task is not exactly 'trivial'. Any serious implementation that seeks to be in compliance with 2518 must meet the specifications set out in 2616 as well, and some of the interactions between the two specifications can be fairly subtle. This is especially the case with respect to both correct locking behavior and the effects of various request headers. If possible, reusing an existing implementation should be made a high priority as opposed to building one from scratch.
This reuse approach proves somewhat of a difficulty though, as there are few open source Java WebDAV libraries available and fewer still that have ASF compatible licenses. Tomcat and Slide are, of course, natural options as they are already ASF projects and there is a recognized benefit to using 'in-house' projects where possible. The DAVExplorer project at UC Irvine has a self-proclaimed "Apache-style license" [1], which appears compatible but it is not really designed as a general purpose WebDAV client library, instead being built upon a generic HTTPClient library which allows arbitrary method names, headers and request bodies to be defined. As such, much of the 'WebDAV logic' in DAVExplorer is not well suited for reuse of their implementation. This is unfortunate because, as of this writing, DAVExplorer is more compliant with 2518 than Slide. SkunkDAV is a more reusable Java WebDAV client library [2], but it uses the LGPL license so really isn't an option in this case without there being some sort of negotiations involved to change the license. SkunkDAV is also out of sorts with the current WebDAV specification and JRE and is undergoing a major overhaul to bring it up to date.
While DAVExplorer and SkunkDAV only provide client implementations, Tomcat only provides a server implementation (which also isn't fully compliant with 2518). In short, unless there is a willingness to use client and server implementations from different projects, and in spite of it's recognized shortcomings, Slide may be the best fit in this situation. This is only tenuously offered as a solution since it would require picking up where the Slide developers have left off to make sure that the compliance issues listed in a previous email are addressed. As mentioned in that email, if more than bare 2518 functionality is required in the future (such as DASL, ACL or Delta-V) there may need to be some major changes made to the Slide library.
So, I think one of the main questions which needs to be addressed is whether it would be an acceptable overhead to use separate client and server implementations in Geronimo. If this is the case, I would recommend trying to use the DAVExplorer client library (with the Slide client library as a fallback option) and the Tomcat servlet implementation for the server side. If not, then I think Slide is the only available option as far as reuse is concerned. Lastly, it may be reasonable to take one of these approaches until a more permanent solution can be implemented from the ground up. Sorry for the rambling - it's late and you must have hit a nerve... If desired, I can try to revisit this issue with more clarity when I'm more rested. :-)
Regards, Elias
[1] DAVExplorer 'Apache-style' license, <http://www.ics.uci.edu/~webdav/client/DAVExp-License.txt>.
[2] SkunkDAV project page, <http://skunkdav.sourceforge.net/>.
