Bill,
> I can't see anything wrong with this proposal. I was more against
> defining any specific interface/api.
I never demanded more than the above. Actually my original proposal was that I do not want ANY API at all if we can agree on caching being automatically enabled, which was objected by others. If we can agree on "A compliant implementation must have http/1.1 compliant client side caching enabled." I do not need any API.
> Then again, how vague can the spec be on this switch? Can the spec say
> "Vendor must support HTTP caching, how it does it, or how it is
> configured is implementation dependent."?
Again, I just want a client to (at least) prevent duplicate requests. So yes, it can be vague like "A compliant implementation must provide a http/1.1 compliant client side cache that is switched on by Client.setProperty(Client.CACHE_ENABLED). It is up to the vendor to decide the actual feature set and operating mode of that cache, as long as it effectively prevents any duplicate *identical* http GETs issues by the application within the past at least the past ten requests." and I would be more than happy with that. This solves the problem of my customers (having a lot of duplicate identical GETs due to the nature of the application and the granularity of the domain objects) and it allows the RI to just use a rather simple HashMap to implement it, and it allows other vendors to come with a fully-featured big super-smart cache to drive local caching to the max (if the way).
Never demanded more.
Regards
Markus
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com