Markus,
I think you are mixing two unrelated things here:
One thing is to let users plug in a cache implementation of their choice to improve performance of your client code.
Nobody is objecting to that IMHO.
Other thing is to propose and standardize a caching API and mandate caching support in JAX-RS all implementations. And
that's something we should avoid without a solid past experience.
Marek
On 05/15/2011 09:39 AM, Markus KARG wrote:
> Just to understand your fear correctly: You really expect it to be of better predictability and throughput to repeat the same http GET again and again? As the target is not under you control and might be totally overloaded, this is the worst case for predictability and throughput. Since a simple ping needs between 50 and 100ms, I cannot share your assumptions that this will be more predictable or faster than just holding *some* recent responses in the local JVM. Again, it's not about getting a second SQUID. It's just about preventing the same GETs again and again done by a Client instance. No need to even share or persists. Nobody would object that it is OK if your implementation decides to just keep the past 100 responses and drop the oldes with every new one. I do not see that such a small cache would impose any unpredictably impact.
>
>> -----Original Message-----
>> From: Bill [mailto:bill_at_dehora.net]
>> Sent: Sonntag, 15. Mai 2011 04:00
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-39]
>> Client Cache Support to MINOR
>>
>>> 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
>>>
>>>
>>>
>
>