Hi Markus,
I gave it more thought and read carefully through all the messages in this thread.
JAX-RS specification does not seem to be the right platform for defining a standard client-side caching API. HTTP
caching API is quite complex and coherent domain that deserves it's own JSR with a dedicated EG formed of experts
specialized on caching domain. Once such JSR is finalized JAX-RS could be updated to reference it.
Such approach would be well aligned with the past JAX-RS as well as overall Java EE platform strategy. Consider e.g.
data binding APIs used in JAX-RS. Data bindings (e.g. JAXB, JSON), while playing an essential role in JAX-RS, are not
defined in the scope of JAX-RS API spec and are covered by separate JSRs instead.
Since we failed to reach (or at least come close to) a consensus about this being a CRITICAL issue we need to downgrade
the issue for now. Instead of spending more effort in attempts to find a common ground in this matter, we should switch
our focus to other critical tasks and issues where we do have a common agreement about their importance and defer the
client-side caching API issue to future reconsideration.
Marek
On 05/07/2011 06:09 PM, Markus KARG wrote:
> 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
>