On 05/13/2011 11:57 PM, Bill Burke wrote:
> WORA could easily be achieved with a properties file. I think Marek and I are on the same page on this. I agree with
> him, I don't think JAX-RS is ready (or is even the right place) to standardize a caching API. As a JAX-RS implementor
> and a cache provider, I personally do not want to be constrained by a specification in this regards. Especially when
> Red Hat is already leading or participating in other caching JSRs.
>
> I think we need to focus on the API/SPIs that give us the abstractions we need to write value-adds like caching.
> Specifically a client framework and client/server side interceptors.
+1. Marek
>
> On 5/13/11 2:17 PM, Markus KARG wrote:
>> How shall an application do WORA then? You are enforcing proprietary apps. That is counterproductive to the idea of a
>> Java EE standard.
>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>> Sent: Freitag, 13. Mai 2011 13:35
>>> To: Marek Potociar
>>> Cc: jsr339-experts_at_jax-rs-spec.java.net; Markus KARG
>>> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
>>> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>>>
>>>
>>>
>>> On 5/13/11 6:34 AM, Marek Potociar wrote:
>>>>
>>>>
>>>> On 05/12/2011 07:43 PM, Markus KARG wrote:
>>>>> Agreed, but in a standalone client application the application's
>>> http transport provider is provided by the JAX RS Implementation, isn't
>>> it? How should an application enable caching then?
>>>>
>>>> Through a proprietary client provider API.
>>>>
>>>
>>> Or through proprietary properties.
>>>
>>> i.e.
>>>
>>> import javax.ws.rs.client.Client;
>>>
>>> Client c = new Client();
>>> c.setProperty("resteasy.client.cache", true);
>>>
>>>
>>> Bill
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>