Markus,
I agree with you that there are real use cases in which caching is important. The question is whether caching should be tackled at the API or at the implementation level. I remember similar discussions years ago in relation to XML schemas in JAXP. After very long discussions, it was concluded that caching was better handled by implementations: there were just too many details that needed to be specified otherwise, which resulted in additional complexity to the spec.
To me this is an area in which implementation X can compete against implementation Y, rather than something that all implementations should support via the exact same API. What level of API support do you envision for caching in JAX-RS? What else beyond the ability to turn caching on/off?
-- Santiago
On May 4, 2011, at 2:01 PM, Markus KARG wrote:
> Marek,
>
> I have to reject your request. From my point of view as a software vendor (not a JAX-RS vendor but a JAX-RS customer) the client API would be completely useless for us and our customers if it will not come with automatic local cache. We have measured in a real world scenario, where the most waiting time is squandered in a sample RESTful application and noticed that it is waiting for unnecessary requests. For example, some master data lookups are running again and again for the same resource. This is typical for RESTful services, and it is the reason why browsers since decades support local caches. Certainly one can implement that caching in the application, but that is weird. First, applications could share a cache, to make it more efficient. Second, it makes no sense to implement caching again and again in every application. So local caches MUST be part of that API. I do not enforce that it can get configured in any way as long as automatically enabled local caching is the default. So, nope, it must not be reduced to minor as it for us is a critical feature of JAX-RS 2. If there will be no caching, we don't need the client API at all.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
>> Sent: Mittwoch, 4. Mai 2011 18:12
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Proposal to downgrade [JAX_RS_SPEC-39] Client
>> Cache Support to MINOR
>>
>> Hello *,
>>
>> I just looked more closely at the feature request #39
>> (http://java.net/jira/browse/JAX_RS_SPEC-39) and it seems to me
>> now that the importance of the proposed feature (standard API for
>> client cache configuration and API for enabling or
>> disabling local caches) is is currently somewhat overrated.
>>
>> The feature looks like a nice to have thing to me. Currently proposed
>> API programming model lets you plug in features
>> like local cache seamlessly without the framework actually knowing
>> about it. Additionally, I believe that configuration
>> is always closely related to an implementation and can be covered by
>> the proposed extensible configuration model.
>>
>> I would like to downgrade priority of the issue to MINOR. Please let me
>> know if you have any objections.
>>
>> Thank you,
>> Marek
>