On 05/13/2011 08:16 PM, Markus KARG wrote:
> Exactly what I fight against! As a Java Expert Group our target must be that no proprietary API must be used.
I disagree. It would be naive to think that we can put together an API that will solve all World's problems in its first
version. Instead, we should aim for a minimalistic API design that is open to proprietary extensions and flexible to
support future additions and extensions as part of the natural API evolution. We do not need to address every aspect in
the first API version.
> Caching is a basic feature of http, and so it must be useable without proprietary stuff.
Caching is also the most complex HTTP feature. There are many other important RESTful features on our plate. Do we
really have to spend all our energy on this single topic now? Going with a proprietary extensions for now is a good
option IMO.
Marek
>
>> -----Original Message-----
>> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
>> Sent: Freitag, 13. Mai 2011 12:35
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Cc: Markus KARG; 'Bill Burke'
>> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
>> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>>
>>
>>
>> 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.
>>
>> Marek
>>
>>>
>>>> -----Original Message-----
>>>> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
>>>> Sent: Donnerstag, 12. Mai 2011 16:31
>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>> Cc: Bill Burke
>>>> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
>> to
>>>> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>>>>
>>>>
>>>>
>>>> On 05/12/2011 01:49 PM, Bill Burke wrote:
>>>>> Caches are essential, but they don't necessarily belong in the JAX-
>> RS
>>>> specification.
>>>>
>>>> +1 for me it's actually one level down. The HTTP transport provider
>>>> should take care of that.
>>>>
>>>> Marek
>>>
>