Just to get it clear: I never said a Client API is not useful without
caches. I said that for *my* customers it is completely useless without
that. Certainly there might be other users that find it useful (while I do
not see what exactly in that new API will be useful then, which couldn't get
simply solved using HTTPUrlConnection or even some code lines around plain
sockets).
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Montag, 9. Mai 2011 14:58
> 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,
>
> 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
> >>>>>
> >>>
> >>>
> >
> >