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