Jeanfrancois,
I am uncertain about the actual WebDAV implementation in AHC, so don't mind
if my question might be silly: WebDAV is an extensible protocol, which
meanwhile contains several additions like Versioning, Links, Search and so
on which had been developed rather late (when WebDAV "base" was in place
already). Also, WebDAV allows custom extensions (mostly for user defined
properties). Is both supported in AHC? Because, supporting that
extensibility is essential for useful WebDAV client APIs, as lots of custom
WebDAV based extensions are in place already (like SharePoint etc).
Regards
Markus
> -----Original Message-----
> From: jfarcand [mailto:jfarcand.oss_at_gmail.com]
> Sent: Montag, 10. Januar 2011 20:11
> To: dev_at_jersey.java.net
> Subject: Re: [Jersey] [WebDAV] Client API
>
> Salut,
>
> AsycnHttpClient supports WebDav BTW. Might be a good opportunity to
> implement AHC support with Jersey client. You will get WebDav for free
> :-)
>
> A+
>
> -- Jeanfrancois
>
> On 11-01-10 4:22 AM, Paul Sandoz wrote:
> > 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>
> >> [mailto:Paul.Sandoz_at_Sun.COM]
> >> *Sent:*Montag, 2. Februar 2009 11:23
> >> *To:*dev_at_jersey.dev.java.net <mailto: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.
> >