On 5/17/11 3:18 PM, Markus KARG wrote:
> Bill,
>
>>> Again, I just want a client to (at least) prevent duplicate requests.
>> So yes, it can be vague
>>
>> I meant, does it violate any best practice or rule of JSR writing, to
>> require a feature, but not really define any of the semantics of the
>> feature.
>
> 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.
> 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com