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
> >>>
> >
> >