wsrp-interfaces message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-interfaces] Questions on the caching sections of the spec
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-interfaces@lists.oasis-open.org
- Date: Thu, 22 Sep 2005 12:17:07 -0400
Comments in this color
Rich
Stefan Hepper <sthepper@hursley.ibm.com>
09/22/05 08:44 AM
|
To
| WSRP Interfaces subgroup <wsrp-interfaces@lists.oasis-open.org>
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]