Well, picking something from the free market *is* implementing caching within the application. What I want is that the application doesn't even know that caching is in place, and happens totally transparently "under the hood" of JAX-RS, just as no html page knows that the browser runs caching inside. So let's rephrase it with your words: Currently every application needs to *solve* the issue of caching on its own, if the word "implements" is what you disagree with.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 5. Mai 2011 13:42
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> 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
> >>
> >