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