> Is that what you meant with "to"?
Sort of, yes. My concern is that such a client results in unplanned
systems problems beyond functional bugs or reference leaks (eg GC pauses
in server systems). I could same the same about clients writing out to a
".cache" folder or reading from it, making throughput unpredictable. I'm
not arguing against _supporting_ cache, but not sure we should be
designed an API directly or implementing it.
Bill
On 11/05/11 20:03, Markus KARG wrote:
> A pure per-client in-memory cache implemented as a client filter would do. No need to dig into shared or persistent caches, as the target is to speed up the single client instance by preventing unnecessary repeated GETs and handling If-Modified and If-Not-Modified conditional requests out of the own JVM's RAM. Is that what you meant with "to"?
>
>> -----Original Message-----
>> From: Bill [mailto:bill_at_dehora.net]
>> Sent: Mittwoch, 11. Mai 2011 01:57
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Cc: Markus KARG; 'Marek Potociar'
>> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-39]
>> Client Cache Support to MINOR
>>
>> On 10/05/11 17:45, Markus KARG wrote:
>>
>>
>>> So I just do not see any technical reason to *not* implement caching
>> in the JAX-RS API
>>
>> I'm not inclined to think we can get a HTTP Cache API right never mind
>> a
>> reference implementation (what would it cache 'to'?).
>>
>>> or have a need for configuration.
>>
>> Ok. I think we could allow a Cache to be "transparently" added as a
>> client filter if the cache directives were cleanly exposed.
>>
>> I imagine we'll have the same discussion on transparently introducing
>> Authorization support so a common pattern seems desirable.
>>
>> Bill
>
>
>