jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR

From: Markus KARG <markus_at_headcrashing.eu>
Date: Tue, 17 May 2011 21:18:34 +0200

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).

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.

But good to see that we come back to discussing features.

Regards
Markus

> On more thought I'm kinda changing my mind on this.
>
> 1. Generally developers are going to want to specify a vendor-specific
> eviction policies and configuration, so I don't see that adding
> ENABLE_CACHE provides any benefit to the specification
>
> 2. THere's also questions of semantics that break WORA as well. DO you
> cache bytes and/or unmarshalled entities. Are the bytes and/or
> entities
> mutable or not? All questions that really need to be answered.
>
> I'm sure there's other issues we haven't thought of that need
> specification as well.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com