I never said we need a SPI. Do you see "SPI" somehwere in my posting?
What I said is that we need exactly one standardized way to let an
application enable caching, unless we agree that caching must be in place
without an application explicitly asking for. The way how an application
does that (with interfaces, class names, or standardized properties) was not
part of my proposal. All I want is that caching is in place on all
implementations without an application having to be changed in a vendor
specific way.
What would be your proposal to do it?
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Donnerstag, 12. Mai 2011 13:54
> 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
>
> I disagree we need any SPI for a cache. #1 I don't want to be forced
> to
> use any specific interface to implement/plug-in my cache. #2, caches
> can be configured by property settings. The user does not need to know
> the implementation details of the cache.
>
> On 5/11/11 3:11 PM, Markus KARG wrote:
> > As long as the spec mandates that every compliant JAX-RS
> implementation must
> > come with a configuration-free private cache, and as long as the spec
> > mandates that the unique way to enable it, this will be ok for me.
> >
> > But if we say the cache is a filter, then we must provide either a
> unique
> > class name for it, or we need a factory for it.
> >
> > If we do not specify name or factory, it would be up to the
> implementor to
> > name the cache class, which would lead to non-portable client code.
> >
> >> -----Original Message-----
> >> From: Bill [mailto:bill_at_dehora.net]
> >> Sent: Mittwoch, 11. Mai 2011 01:37
> >> 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
> >>
> >> I agree with Julian. IMO
> >>
> >> - just designing a well formed HTTP Cache that could be plugged
> into
> >> will be an effort that will alter the scope/schedule of this eg. It
> >> also
> >> begs the question of default providers.
> >>
> >> - Caching in Java seems to be area where we like implementors to
> >> innovate. And the heuristic/distributed nature suggests it'll be a
> >> while
> >> before there's an ultimate client side caching technology ;).
> >>
> >>
> >> Markus, Marek, can we compromise for now by
> >>
> >> 1 : Indicating how one could introduce a cache via client filters.
> This
> >> allows users to source the cache impl separate from the client impl.
> >>
> >> 2: Ensuring that the cache http directives are exposed clearly in
> the
> >> client API and possibly including some exception handling support
> >> things
> >> like 409 (not unlike I get convenience methods like ok() and
> created()
> >> in the server. This gives the cache implementor programmatic access
> to
> >> the request data. It also helps us focuses on Bill's point that we
> need
> >> to get the low level API right, and we can use cache introduction as
> a
> >> form of sanity check.
> >>
> >> ?
> >>
> >> Bill
> >>
> >> On 07/05/11 15:32, Julian Reschke wrote:
> >>> On 07.05.2011 15:44, Markus KARG wrote:
> >>>> Decoupling is just a means to get a particular improvement, not an
> >>>> improvement by itself - but it is added complexity and such adds
> >> possible
> >>>> cause of failure. So what will *this* decoupling actually provide
> >> *here*,
> >>>> despite the problems I already mentioned in my last posting?
> >>>> ...
> >>>
> >>> Well, decoupling would require us to define a proper caching API,
> >> which
> >>> isn't trivial, but might help implementers get their code right.
> >>>
> >>> Consider all the things you have to get right:
> >>>
> >>> - properly handling Conneg (Vary...)
> >>> - special casing Cookies
> >>> - working around server bugs with compression
> >>> - properly handle extension status codes/methods
> >>> - invalidation
> >>> - heuristic expiry
> >>> - parsing Cache-Control/Pragma
> >>> - range requests
> >>>
> >>> etc.
> >>>
> >>> Don't get me wrong, it would be awesome to get a clean Java
> >>> implementation of the HTTP caching model; optimally following what
> >> the
> >>> HTTPbis WG is doing in
> >>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-
> >> 14.html>.
> >>>
> >>> Best regards, Julian
> >>>
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com