Markus,
Thanks for elaborating on your proposal. As I said in my previous message, I believe there are use cases in which this proposal can be useful. However, I think there are use cases in which it can be problematic.
One such case is using the client API in a server environment (like an EE container). In this scenario, there could be hundreds of threads executing concurrent requests using the client API. Having a single, shared cache could actually result in worse rather better performance (with additional problems like disk usage, cache replacement policies, etc.). This is where the analogy with the web browser falls short IMO. Moreover, problems that result from _transparent_ features like these are incredibly hard to find, especially when (system) developers are not necessarily JAX-RS experts.
As a result, I agree with Marek and Bill that this should be a low priority issue.
-- Santiago
On May 5, 2011, at 12:40 PM, Markus KARG wrote:
> 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
>>>
>
>