I understand what you like to tell, but still do not see the problem. If I
would not implement features just because it imposes to use my brain and
spend lots of time, I should not go into office at the mornings. This is
Oracle in the end, so who if not them should provide a Java based cache? If
we all fear to fail all the time, we better not start with anything.
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke_at_gmx.de]
> Sent: Samstag, 7. Mai 2011 16:32
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> 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