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