I think I got misunderstood.
What I want is that *every* JAX-RS client api implementation must
automatically apply caching as described by the http RFC.
*If* the implementation *needs* configuration to turn on or run the cache,
*then* it must be configurable using a standard API.
I want to prevent that in the end, everybody has caching implemented in his
JAX-RS engine, but to turn it on the application needs to be modified or
annotated or appended by XML files etc.
I could imagine that it can be solved very easily by a few clear words in
the spec:
* Every JAX-RS Client API implementation MUST support caching according to
the http RFC. That means, it MUST check first the local cache with respect
to modified-since etc provided by the calling application with every method
invocation done by the calling application. As a result, using the cache is
fully transparent to the calling application.
* This cache MUST be enabled by default and it must be fully functionaly
according to the http RFC, i. e. neither the application provider nor the
deployer or administrator must do anything to enable it.
* The cache implementation MUST support ETags AND modification dates,
according to http 1.1
* If an implementation supports configuration of the cache, the
configuration is to be done (at least) using
Client.setCacheConfiguration(Properties). Calling this API or not calling it
is in the sole grace of the application provider. An engine MUST NOT enforce
any kind of configuration to be enabled or to run in a http 1.1
fully-compliant mode. The JAX-RS specification does not specify what
properties do exist, as configurability of the cache is an optional feature.
Just to discuss the same things. :-)
BTW, my target in this EG is not to make it easy to implementors or to have
a chance to have different implementations, but it is to make it easy for
application providers and to have a unique set of features (WORA, you know).
Regards
Markus
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Mittwoch, 4. Mai 2011 22:09
> 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
>
> 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
> >