Those things cannot be divided until JAX-RS exposes the transport to the application (what breaks the layer model). I do not know anybody wanting to plug in a custom cache implementation. I only know people wanting to get caching out of the box. But maybe I know the wrong customers? ;-)
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Montag, 16. Mai 2011 11:05
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG
> Subject: Re: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-
> 39] Client Cache Support to MINOR
>
> Markus,
> I think you are mixing two unrelated things here:
>
> One thing is to let users plug in a cache implementation of their
> choice to improve performance of your client code.
> Nobody is objecting to that IMHO.
>
> Other thing is to propose and standardize a caching API and mandate
> caching support in JAX-RS all implementations. And
> that's something we should avoid without a solid past experience.
>
> Marek
>
> On 05/15/2011 09:39 AM, Markus KARG wrote:
> > Just to understand your fear correctly: You really expect it to be of
> better predictability and throughput to repeat the same http GET again
> and again? As the target is not under you control and might be totally
> overloaded, this is the worst case for predictability and throughput.
> Since a simple ping needs between 50 and 100ms, I cannot share your
> assumptions that this will be more predictable or faster than just
> holding *some* recent responses in the local JVM. Again, it's not about
> getting a second SQUID. It's just about preventing the same GETs again
> and again done by a Client instance. No need to even share or persists.
> Nobody would object that it is OK if your implementation decides to
> just keep the past 100 responses and drop the oldes with every new one.
> I do not see that such a small cache would impose any unpredictably
> impact.
> >
> >> -----Original Message-----
> >> From: Bill [mailto:bill_at_dehora.net]
> >> Sent: Sonntag, 15. Mai 2011 04:00
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-39]
> >> Client Cache Support to MINOR
> >>
> >>> Is that what you meant with "to"?
> >>
> >>
> >> Sort of, yes. My concern is that such a client results in unplanned
> >> systems problems beyond functional bugs or reference leaks (eg GC
> >> pauses
> >> in server systems). I could same the same about clients writing out
> to
> >> a
> >> ".cache" folder or reading from it, making throughput unpredictable.
> >> I'm
> >> not arguing against _supporting_ cache, but not sure we should be
> >> designed an API directly or implementing it.
> >>
> >> Bill
> >>
> >> On 11/05/11 20:03, Markus KARG wrote:
> >>> A pure per-client in-memory cache implemented as a client filter
> >> would do. No need to dig into shared or persistent caches, as the
> >> target is to speed up the single client instance by preventing
> >> unnecessary repeated GETs and handling If-Modified and If-Not-
> Modified
> >> conditional requests out of the own JVM's RAM. Is that what you
> meant
> >> with "to"?
> >>>
> >>>> -----Original Message-----
> >>>> From: Bill [mailto:bill_at_dehora.net]
> >>>> Sent: Mittwoch, 11. Mai 2011 01:57
> >>>> To: jsr339-experts_at_jax-rs-spec.java.net
> >>>> Cc: Markus KARG; 'Marek Potociar'
> >>>> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-
> 39]
> >>>> Client Cache Support to MINOR
> >>>>
> >>>> On 10/05/11 17:45, Markus KARG wrote:
> >>>>
> >>>>
> >>>>> So I just do not see any technical reason to *not* implement
> >> caching
> >>>> in the JAX-RS API
> >>>>
> >>>> I'm not inclined to think we can get a HTTP Cache API right never
> >> mind
> >>>> a
> >>>> reference implementation (what would it cache 'to'?).
> >>>>
> >>>>> or have a need for configuration.
> >>>>
> >>>> Ok. I think we could allow a Cache to be "transparently" added as
> a
> >>>> client filter if the cache directives were cleanly exposed.
> >>>>
> >>>> I imagine we'll have the same discussion on transparently
> >> introducing
> >>>> Authorization support so a common pattern seems desirable.
> >>>>
> >>>> Bill
> >>>
> >>>
> >>>
> >
> >