Hi Markus,
Have you had a look at the Jersey client API?
While it was not designed with WebDAV in mind i believe it is
sufficiently extensible to support WebDAV. It supports filters and
does not limit what HTTP methods are supported. I think the area that
requires more work is the improvement of that extensibility such that
WebDAV like extensions don't feel like second class citizens :-) e.g.
specificly the area of the resource builder extensibility could be
improved and ensure such extensions work for sync/async use-cases.
Paul.
On Jan 8, 2011, at 4:48 PM, Markus Karg wrote:
> Paul,
>
> pickung up this two year old thread, now that the JSR for JAX-RS 2.0
> is planned to include a standard API for clients, I'd like to go on
> with the idea of the possibility for custom client API extension.
> You know that I am providing a JAX-RS based extension for WebDAV (http://webdav.dev.java.net
> ) and certainly this shall support the client API once it is
> standardized. As there is no JAX-RS 2.0 JSR currently (and such, no
> official proposal for the client API) I'd like to know if you are
> planning to propose a extension points in that API and what they
> would look like?
>
> Thanks
> Markus
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Montag, 2. Februar 2009 11:23
> To: dev_at_jersey.dev.java.net
> Subject: Re: [Jersey] [WebDAV] Client API
>
>
> On Jan 31, 2009, at 12:16 PM, Markus KARG wrote:
>
>
> This week we discussed ideas for a WebDAV Client API. Craig asked
> for something that will be as simple as "WebDAV.listDirectory(URL)"
> and what returns Java Beans. From the user's perspective this sounds
> great, but the question is: What shall this Java Bean contain? The
> WebDAV directory describer (i. e. a JAXB wrapper around the WebDAV
> XML Tags)? Or the directory as a bean, so one can use
> directory.listDirectory() for subdirectories and file.get() to
> receive the content? Or when it is a file, the file content itself
> (which will be a performance problem since it might pull thousands
> of files then).
>
>
> My hunch is that it would be useful for links in the Java Bean to be
> easily accessible as "WebResource" types from which further
> operations can be performed by the client. Such functionality is
> likely to be a thin wrapper to something that creates an instance
> from a URL, but it avoids the developer having to "pop out" of what
> they are focusing on.
>
>
>
> What do you think? What shall the client API be like?
>
> And what is the Jersey Client currently providing? Can it be
> extended to support this or would it be better to provide something
> "ontop"?
>
>
> Browse the client API:
>
> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/package-summary.html
>
> At the moment it would be more suited for wrapping, but i would be
> happy to make backward compatible changes to make it extensible.
>
> Paul.
>
>