Craig McClanahan wrote:
> I have indeed looked at Jackrabbit's WebDAV client code, and use it in
> some applications as well. My only real issue with it is that it
> exposes all the complexity of WebDAV at a very low level of granularity
> -- you have to be pretty deeply familiar with the WebDAV specs to
> understand how to construct request bodies that are meaningful, as well
> as interpret the response bodies. In addition to that level of support,
> I'd like to have something a bit higher level, along the lines of a call
> to get the files in a directory (a PROPFIND of all properties of a
> collection, in WebDAV-speak) that gives me back a list of simple
> javabeans, one per file, with properties like name, size, creationDate,
> and a boolean flag that says whether this is a subdirectory or not.
> Making me have to parse a MultiStatusResponse to get that data is cruel
> and unusual punishment :-).
That is true. The low level view may be necessary in some cases, but I
agree that something more high-level (built on top?) would be desirable
as well.
> An irritant-level concern is that the Jackrabbit client uses Apache
> Commons HttpClient for its low level communiciation engine, rather than
> java.net.HttpURLConnection. It works, but makes some classes of
> debugging HTTP problems (like bad certificates) a little more
> complicated to deal with since you have to deal with two stacks instead
> of one. Getting Jersey to the point that it could optionally run on
> HttpClient as well would make that irritant go away.
How would java.net.HttpURLConnection work with the HTTP method names
that are used in WebDAV?
Best regards, Julian