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: Bill <bill_at_dehora.net>
Date: Wed, 11 May 2011 00:37:11 +0100

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
>