> > I do not see that this violates a best practice as I have seen lots
> of vague things like that in JSRs already. And, the feature is fully
> describes by http/1.1 as this is a clear and unique specification,
> identified by RFC 2616
> http://www.w3.org/Protocols/rfc2616/rfc2616.html.
> >
> > That also answeres the question regarding bytes vs. entities: A
> http/1.1 compliant cache is working on the byte level and does not know
> anything about entity marshalling (in the sense of JAXB which I expect
> you meant).
> >
>
> There's still the question of mutability/copies.
I think this question is answered by RFC2616.
> > Also, I have to object that the typical Client API user is interested
> in vendor-specific cache configuration. We just seem to have different
> kind of customers and experience and need to accept that yours will be
> happy with fiddling around with vendor-specific stuff, while ours just
> want to run a WAR without toughing anything.
> You're missing my point. ENABLE_CACHE isn't enough. Setting the
> eviction policy, no matter how simple it is, is something most users
> will need to do. Some will want max entries config, others will want
> max-bytes config. Is it LRU? Then there is clearing the cache,
> sharing
> the cache, etc.
> This is why myself, and I think others, don't want to head down this
> path as it starts to open up a can of worms we don't want to deal with.
Understood your point, but the can of worms is asking that questions. Many of them are answered by above RFC. It is possible to implement RFC2616 without even thinking of that user wishes. If a user explicitly wants to have a particular policy, he can use a different (proprietary) cache implemented as a setFilter -- as HIS application has THAT particular wish, this is OK for me and it is straightforward that HIS application implements such a special cache. No problem with that. Remember, I suggested enabling the cache that way? I just want that all those many people not in the need of a particular (additional) caching shall get a simple cache built-in. That's why my favorite still is "Client.setFilter(Client.CACHE_FILTER)" which allows a customer to just use a different filter if he wants, or live with the default policy decided by the vendor of CACHE_FILTER.
I share your opinion that nobody wants to open a can of worms. But that not necessarily results in a cache-ignoring spec.
Regards
Markus