Rob Heittman <rob.heittman <at> solertium.com> writes: > > > > I have to ask - why not just WebDAV here? Subversion supports it already, AFAIK. > > I tend to agree, but pragmatically it's not that easy. WebDAV isn't quite a done deal in Restlet yet, though > it's possible with some extra flexing, as some recent threads here rehearse. >
Thank you both for your replies. I think you are right that WebDAV comes close (or likely surpasses) what I need and that I can learn much there. I had already tried to understand how Apache uses WebDAV with Subversion, including the auto-versioning functionality. This section of the SVN book seems to agree with your points: http://svnbook.red-bean.com/en/1.4/svn.webdav.basic.html I'm splitting this response in two parts: ============= USING RESTLET (no WEBDAV yet) ============= My main initial goals are a) to let my existing client software read the HEAD from the file tree easily, and b) to easily write to the file tree (upload new versions). Let me wave my hands a bit ;) 1. I'd like clients that only read from the file tree to be able to do so with standard HTTP GET, such as Java's built-in URLConnection. For the HEAD version, this essentially means exposing the repo structure as a web-accessible file hierarchy. Apache-based SVN does this already. 2. Initially clients with write-access only need a few simple operations, limited to individual files: add (POST), replace (PUT), delete (DELETE) 3. Ideally I'd like a simple URL-based syntax for read access to past versions, such as query parameters ( ?v=390 ). Would be great if the Apache SVN modules could be made to work this way, but I don't know how to do that. I've managed to get a simple version of #1 and #3 working. I'd appreciate feedback on how I've done this so far, and how I should proceed for #2: RestletTest: - main entry point - collects server port, and SVN repo URL and auth credentials from command line - creates a Component; adds an HTTP server; creates an Application from the component; creates a Router; attaches a SVNRestlet for /svn; starts it all SVNRestlet: - extends Finder; all it does is some custom initialization: - super(context, SVNResource.class) - uses the SVNKit library to create an SVNRepository for the specified SVN repo, and adds a reference to this into the Context, so that SVNResource instances can get a handle to the repo (is using the Context's attributes map in this way recommended?) SVNResource: - extends Resource - initialization: creates a single Representation and adds it to the Variants - createMainRepresentation: the bulk of the work - extracts the intended SVN path from the request: request.getResourceRef().getRelativeRef().getRelativePart(); - extracts the intended SVN version from the request's query portion (-1, empty, or unparseable is interpreted as HEAD version) - checks what's in the repo at said path and revision - sets response status code if error, and return a null Representation - or, if such a file exists - tries to determine MediaType from an SVN mime-type property - if not present, uses */* MediaType - creates an SVNFileRepresentation with this MediaType - this inherits from OutputRepresentation and writes the file contents to the OutputStream - or, if it's a versioned directory - fills a ReferenceList with the relative paths for each directory entry - return ReferenceList.toWebRepresentation() Example URL: http://localhost:8182/svn/restsvn/src/com/blabla/restsvn/SVNRestlet.java?v=9 In the SVN repo, the path is: /restsvn/src/com/blabla/restsvn/SVNRestlet.java How am I doing so far? How should I proceed to allow PUT, DELETE, POST? Override put(), etc. in my SVNResource class? Any help would be greatly appreciated. > And the versioning aspects of Subversion are not strictly even WebDAV. RFC 3253, "WebDAV Delta V," (WebDAV > Versioning Extensions, http://www.webdav.org/deltav/protocol/rfc3253.html) has very few actual > implementations, and no ubiquitous open source ones. Subversion made the decision to use a subset of RFC > 3253 and to map this onto svn operations in a way that valued interoperability with existing "regular" > WebDAV clients, over strict compliance with the RFC 3253 standard. (I was participating in the > Subversion list at the time these decisions were initially taken, so I sort of recall the debate ... but I > haven't looked it up, somebody correct me if I'm misquoting) > > Anyway, if Restlet had robust WebDAV Level 1 semantics (which it doesn't yet, but I think we've agreed it > will), it still wouldn't be much of a Subversion client if you're primarily interested in the versioning aspects. > > - R > > ============= WEBDAV ============= Since what I want seems to be mostly a subset of WebDAV - an established standard - and since Subversion implements HTTP communication using WebDAV, and since Apache integrates Subversion using WebDAV, I will consider an approach that builds on WebDAV. Certainly it would be a nice additional benefit to provide generic WebDAV (+DeltaV auto-versioning) access to my file tree, allowing any WebDAV client to be used for reads and writes. This is not a requirement now (all writes will originate from my client application), but I think it would increase the usefulness of my file tree looking forward. Unfortunately, as Rob mentions, finding a WebDAV client library for Java has proved difficult: Jakarta Slide - should have Java HTTP and WebDAV client lib, and work nicely with Apache, but this project has been retired (3Nov2007); seems I may still be able to use the client lib Apache JackRabbit - maybe takes over for Jakarta Slide, but I don't yet see how it does what I need; implements the Java Content Repository spec IBM DAV4J - billed as a Java WebDAV client library, but no longer exists SkunkDAV - Java WebDAV client, but dead Eclipse - also dormant: http://dev.eclipse.org/viewcvs/index.cgi/platform-webdav-home/main.html?view=co Comprehensive list of clients, client libs, servers: http://ftp.ics.uci.edu/pub/ietf/webdav/implementation.html A recent thread with various suggestions for how to do this, reaching roughly the same conclusions (i.e. old Slide lib maybe): http://www.nabble.com/-OT--webdav-client-libraries-for-Java--t4764351.html And talk amongst JackRabbit developers of creating a replacement for the old Slide WebDAV client: http://www.nabble.com/Webdav-Client-Examples--t4803755.html I did get a hold of an old Slide Webclient .jar and some documentation. Looking through the javadoc, however, it doesn't feel like a good match. It's worth spending some more time on, though.
