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

Comments in this color

Rich 

Stefan Hepper <>

09/22/05 08:44 AM

To

WSRP Interfaces subgroup <>

cc

Subject

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

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?

RT> While a Consumer could keep this
straight (it did send the original validateTag), it would be cleaner to
require the new CacheControl structure to resupply the original validateTag.

> 

> - 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?

RT> I know there were arguments
against making this a MUST, any reason the should doesn't become conformance
language (i.e. SHOULD)?

> 

> - why is the concept of HTTP weak validators that allows to have the

> same validation token for slightly different content not supported?

RT> I don't remember any discussion
around weak validators. Anyone care to comment on the value vs complexity?

> 

> 

> Thanks.

> 

> Stefan