On 11-01-13 11:40 AM, Markus Karg wrote:
> Well, the small problem is that this conflicts with the JAX-RS based WebDAV
> implementation I am providing independent of Jersey and that I actually
> wanted WebDAV to be independent of any vendor. If we would implement it
> (again) with AHC, then how to be vendor independent? The only way would be
> to write the WebDAV parts of the client into the JAX-RS spec to force other
> JAX-RS clients to do the same.
Agree. but currently all vendors have different client API right? You
must have some kind of plugin API in your project in order to make it
work, or you ship with your own http library (oh no, not Apache Http
Client ;-)) I don't see how you can support Wink, Jersey or RestEasy
uniformly right now without skipping their HTTP client impl.
So the idea here is to at least add the hook in Jersey client to be able
to support WebDav (via AHC). Then your framework can build on top of it.
Does it make sense?
-- Jeanfrancois
>
>> -----Original Message-----
>> From: jfarcand [mailto:jfarcand.oss_at_gmail.com]
>> Sent: Donnerstag, 13. Januar 2011 14:31
>> To: Markus Karg
>> Cc: dev_at_jersey.java.net
>> Subject: Re: [Jersey] [WebDAV] Client API
>>
>> Salut,
>>
>> On 11-01-11 4:00 PM, Markus Karg wrote:
>>> 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).
>>
>> Right, AHC support the basic method but you can customize it much more
>> easily than Apache Http Client.
>>
>>
>> Also, WebDAV allows custom extensions (mostly for user defined
>>> properties). Is both supported in AHC?
>>
>> Yes
>>
>> 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).
>>
>> Again, WebDav in AHC is minimal, but building on top of it is pretty
>> simple. Since we already agree we wanted the Jersey Client to support
>> AHC, it may be a good idea to think about WebDav as well.
>>
>> A+
>>
>> --Jeanfrancois
>>
>>
>>
>>>
>>> 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.
>>>>>
>>>
>>>
>
>