jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR

From: Markus KARG <markus_at_headcrashing.eu>
Date: Thu, 12 May 2011 19:37:00 +0200

Where else would you place it then? In the application? Nope, caches are
part of the infra structure and applications are the totally wrong place. In
the JVM? Nothing against it. There is already an interface for that in
HTTPUrlConnection. But as the application is not using HttpUrlConnection but
the JAX RS Client API, how to tell the Client to use a cache then? So where
to put it if not in the JAX RS API?

Besides that, since JAX RS deals with Cache headers already (and it does it
well), I think JAX RS is a great place for that.

Regards
Markus

> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Donnerstag, 12. Mai 2011 13:50
> 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
>
> Caches are essential, but they don't necessarily belong in the JAX-RS
> specification.
>
> On 5/11/11 3:07 PM, Markus KARG wrote:
> > Thank's Jan for chiming in. I actually *only* meant *private* cache,
> maybe I
> > was not clear with that before.
> >
> >> -----Original Message-----
> >> From: Jan Algermissen [mailto:algermissen1971_at_me.com]
> >> Sent: Dienstag, 10. Mai 2011 19:00
> >> 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
> >>
> >> (Sorry for top posting - but it does not really fit inline)
> >>
> >> One thing to consider is that there is a significant difference
> between
> >> just any cache and the user agent's private cache. Because cache-
> >> control can differentiate between the two.
> >>
> >> In my experience, in an enterprise IT context, public caching is not
> >> that interesting because you want to avoid the possible defects of
> >> whatever public cache is out there in your system. Private caching
> >> however is essential for building a performant system then. (REST's
> >> performance depends on caching by design)
> >>
> >> In my opinion, support for private caching is one of *the* mission
> >> critical aspects and Java clients have lacked this ability far to
> long.
> >>
> >> I am with Markus there.
> >>
> >> Jan
> >>
> >>
> >>
> >> On May 10, 2011, at 6:40 PM, Markus KARG wrote:
> >>
> >>> I doubt that anywhere along the long line between my browser and my
> >> favorite
> >>> online shop, the shop software vendor had any chance to influence
> the
> >> cache
> >>> settings applied by me, my provider, or the provider's uplink...
> >>>
> >>>> -----Original Message-----
> >>>> From: Santiago Pericas-Geertsen
> >>>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> >>>> Sent: Montag, 9. Mai 2011 21:23
> >>>> 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
> >>>>
> >>>>
> >>>> On May 9, 2011, at 1:08 PM, Markus KARG wrote:
> >>>>
> >>>>>
> >>>>>> Yes, exactly. Possible but non-trivial is an accurate statement.
> >> I'm
> >>>>>> also skeptical about a single caching configuration that would
> >> work
> >>>>>> well for all use cases out of the box.
> >>>>>
> >>>>> I wonder how the web is working then, since there are lots of
> >> caches
> >>>> all the
> >>>>> way and you have no access to their config at all.
> >>>>>
> >>>>
> >>>> Even if I can't access them, it does not imply they aren't
> >> configured
> >>>> and tuned by other people based on some requirements. From my
> point
> >> of
> >>>> view, this set of requirements can vary significantly when
> >> considering
> >>>> the Client API use cases for a one-size-fits-all, transparent
> cache
> >> to
> >>>> be mandated.
> >>>>
> >>>> -- Santiago
> >>>
> >>>
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com