Re: [wsrp-interfaces] Questions on the caching sections of the spec

[Stefan Hepper <sthepper@hursley.ibm.com>]

Just saw that you can specify 0 as expiry value to indicate that the 
content is not cacheable. So my first question can be ignored.

Stefan

Stefan Hepper wrote:
> While reading the current WSRP draft and the HTTP spec I noted some 
> differences between caching defined in WSRP and in HTTP. Can someone 
> please explain why WSRP derives from HTTP in these points:
> 
> - a producer cannot specify that a piece of markup must not be cached
> 
> - 6.2.1.1 states: "Portlets indicating the cached markup can be used 
> SHOULD also supply a new CacheControl structure with a new expiry for 
> the markup. "
> shouldn't it also state that the validation token should be set and that 
> the current validation token should (or even must) be reused? If the 
> producer sets a new validation token for the cached response, how does 
> the consumer know which validation token to replace?
> 
> - 6.2.1.2 states: "Consumers should be aware that invoking 
> performBlockingInteraction and/or handleEvents may cause cached markup 
> to become invalid. "
> doesn't this need to be stronger? I would have expected at least a 
> SHOULD. How can otherwise the producer expect to be called with 
> getMarkup after an action that invalidates the cache entry?
> 
> - why is the concept of HTTP weak validators that allows to have the 
> same validation token for slightly different content not supported?
> 
> 
> Thanks.
> 
> Stefan
> 
> 
> 
>