cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21878] New: - [PATCH] Another sample for the WebDAV block
Date Fri, 25 Jul 2003 09:44:49 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21878>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21878

[PATCH] Another sample for the WebDAV block

           Summary: [PATCH] Another sample for the WebDAV block
           Product: Cocoon 2
           Version: Current CVS 2.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: sitemap components
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: gcasper@s-und-n.de


Inspired by an email of Michael Homeijer
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103483890724049&w=2
I created a first version of a DAVmap, a sitemap serving as a WebDAV server.

If you extract the zip file to <cocoon-context>/samples/webdav, you can mount
http://localhost:8888/samples/webdav/davmap/repo
as a webfolder.

I tested it with Windows Explorer on win2k, with XML Spy, an application build
on the Slide WebDAV client library and the WebDAVSource (yes, that means you 
can use Cocoon as its own WebDAV repository :-)

As this again is based on Cocoon's source resolving you could expose your CVS
repository via Sylvain's CVSSource or a Xindice Database (given someone 
implements TraversableSource and maybe ModifiableSource in XMLDBSource).
You could even integrate some data of a SQL table or just proxy another WebDAV
server (to leverage its versioning or to plugin some workflow logic).

It currently only works, with XML files, but since soon everything will be 
XML ... ;-)
You cannot move, copy, delete, proppatch and mkcol. propfind always delivers
the same properties (what is available through the TraversableGenerator), no 
matter what was requested, so it's not quite to the spec :-)

The sitemap is quite big, partially due to the use of the MethodSelector (and 
the handling of missing trailing slashes). It could be vastly simplified by the 
use of a (not yet existing) MethodAction.

propfind can be more stabilized by extending StreamGenerator (as could 
proppatch).

In order to create new documents via Windows Explorer I had to patch 
StreamGenerator (will send that in a separate patch), since Windows Explorer 
does not set the Content-Type header (and this time MS is not the only one 
doing that :-).

Mime
View raw message