Hi Markus,
I can only second to what Santiago wrote. The API has to be pluggable to allow users to plug in some cache
implementation as well as framework implementors to provide cache impl as an extra feature. I believe that such
requirements are satisfied.
Also, I 100% agree that client-side caching is useful. Yet the argument that each application would now need to
implement it's own caching sounds improbable. Caching is a well defined and generic enough problem to be addressed by a
standalone reusable library. Users would be able to to pick any such implementation from a vendor of their choice and
just plug it in.
Marek
On 05/04/2011 10:09 PM, Santiago Pericas-Geertsen wrote:
> 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 th
e 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
>>
>