On 06.05.2011 16:17, Santiago Pericas-Geertsen wrote:
> Markus,
>
> Thanks for elaborating on your proposal. As I said in my previous message, I believe there are use cases in which this proposal can be useful. However, I think there are use cases in which it can be problematic.
>
> One such case is using the client API in a server environment (like an EE container). In this scenario, there could be hundreds of threads executing concurrent requests using the client API. Having a single, shared cache could actually result in worse rather better performance (with additional problems like disk usage, cache replacement policies, etc.). This is where the analogy with the web browser falls short IMO. Moreover, problems that result from _transparent_ features like these are incredibly hard to find, especially when (system) developers are not necessarily JAX-RS experts.
> ...
Well.
HTTP caches not only live in User Agents, but also in intermediaries. So
it's definitively *possible* to write well-performing cache
implementations (Squid comes to mind).
That being said, caching is totally non-trivial; and having a broken
cache implementation may be worse than not having a cache at all.
Maybe this is something that should be pluggable?
Best regards, Julian