Markus,
Just to clear. I never said that the API is targeted mainly at the server side. I simply said that there are other use cases that needed to be considered in addition to the one you elaborated.
I disagree that a Client API is only useful if it provides transparent caching. Ease of use is the main reason I see developers using the Client APIs provided by some JAX-RS 1.0 implementations.
-- Santiago
On May 7, 2011, at 7:02 AM, Markus KARG wrote:
> Transparent caching is the *only* real benefit we (and our customers) would
> have from a JAX-RS client API. Everything else is easy to solve in JAX-RS 1
> with existing Java SE means. If this is not included in JAX-RS 2, I do not
> see why we should provide a client API at all. 100% of my use client API
> cases are Java SE only, and I do not need a client API on the server. So if
> the client API is mainly targeting server side use, it misses the primary
> use case and is just useless.
>
> I see that server side use might be complex, but we should concentrate on
> client side use first and then discuss how to solve server side issues. I am
> pretty sure we can find a solution, as long as we all are interested in
> providing the best possible approach instead of just getting certified to be
> JAX-RS 2 compliant ASAP by reducing the necessary code changes more and more
> until every already finished implementation matches it.
>
> Would be nice if the other non-vendor-experts would tell what they think
> about a *Client* API that comes without caching support and is targeted for
> *Server* side mainly. Currently this looks like a "let the vendors do what
> they can do with least effort" conference, what -in my opinion- is not the
> idea of an EG.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Santiago Pericas-Geertsen
>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
>> Sent: Freitag, 6. Mai 2011 16:18
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
>> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>>
>> 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
>>>>>
>>>
>>>
>
>