My understanding of the F2F dicussion about caching was something like
this (wrote it up during the discussion):
.Portlet metadata indicates what elements of the request are to be
used as cache keys:
* Markup
* Locale
* Navigational state
* SessionID
.Consumer uses (above) metadata to create consumer-key
.Producer returns producer-key & expiration with getMarkup
.Producer-key should be created using a hierachical namespace that
allows later batch invalidation based on a prefix of the producer-key
.Consumer caches the fragment with two access keys (consumer-key,
producer-key)
.Consumer discards cache entry on expiration
.Consumer queries cache using consumer-key on new requests to the
portlet
.On perform action producer may return producer-key prefix to
invalidate cache entries (the producer-keys are opaque to the
consumer, their only purpose is cache invalidation upon actions)
Tamari, Yossi wrote:
> I still don't see how option 1 can work, but I'd be happy to see a proposal.
> If we want to go for simplicity (I do...) we can add another return
> parameter parallel to the validationTag, that defines the cachingScope.
> It can be an enumeration, where 1 means user scope, and 2 means producer
> scope. These are the two scopes which I see as a must.
> Additionally we can add cachingScope 0 which means session, without
> which producer may have to mark session dependent content as uncachable.
> Another optional scope is the entity scope, but I don't see any use case
> for separating this from the producer scope.
>
> Yossi.
>
> -----Original Message-----
> *From:* Gil Tayar [mailto:]
> *Sent:* Tuesday, September 24, 2002 6:40 AM
> *To:*
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> Now I get you.
>
> Actually, you're right. I forgot about that part.
>
> We can approach it two ways -
> 1. The way you suggested - the Producer encodes the parameters of
> the difference into validationTag. I'm not sure why this wouldn't work.
> 2. Draft something (as discussed in the F2F) about the portlet
> defining which parameters of the request to getMarkup are the key to
> the cache entry.
>
> I am, for simplicity, inclined for the first proposal, but am ready
> to draft the second one. What is the opinion of the TC?
>
> Gil
>
> -----Original Message-----
> *From:* Tamari, Yossi [mailto:]
> *Sent:* Mon, September 23, 2002 13:53
> *To:* 'Gil Tayar';
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> The need for different scopes of caching:
> Say I have a portlet that is cached by the consumer, scoped to
> the producer. Say this portlet is capable of personalization
> through the edit mode.
> First user U1 asks for this portlet and gets his personalized
> content. Then user U2 asks for the same portlet, but his
> personalization info is different. He will get the cached
> portlet with U1's personalization! Now assume user U1 also went
> into edit mode, got the edit page with his current settings, and
> pressed cancel. The cache was not invalidated. Now U2 goes into
> edit mode - he will get the cached edit page with U1's choices
> as his choices!
> This demonstrates the need for user-scoped caching.
>
> The need for session scoped caching is demonstrated by: a user
> opens a portal page, a session is created for a portlet in this
> page, the user navigates in this portlet (actions), thereby
> changing the session information. He ends up with page #4 (of
> the portlet), and some session information that is related to
> how he got to this page. page #4 is cached. Now he closes his
> browser and open a new one. The session is killed. He navigates
> to page #4 through the cache, never actually going to the
> producer. Then he navigates to page #5, forcing a WSRP request
> to the producer. However, the producer can't service this
> request - it needs the information that was gathered in pages 1-4.
> It is possible to create a portlet that will not have this
> problem, by encoding all information in the URL, but I don't
> think it is reasonable to demand this.
>
> In the F2F discussion about caching we suggested using, in
> addition to the mechanism you suggest, all the parameters of the
> action as keys to the cache, and allowing a portlet to define
> which parameters can be ignored. I was missing this in your
> suggestion. One way to implement this is by telling the producer
> it needs to encode these parameters into the validationTag, but
> unless the consumer knows the encoding algorithm it does not
> really work
>
> Yossi.
>
> -----Original Message-----
> *From:* Gil Tayar [mailto:]
> *Sent:* Monday, September 23, 2002 12:44 PM
> *To:* Tamari, Yossi;
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> The spec says that the "expires" is a placeholder for a real
> caching mechanism. My proposal was intended to replace it.
>
> I didn't say it works around the need for other scopes (I'm
> not certain what those needs are). I said that it doesn't
> look to have problems that the other scopes /do/ have.
>
> Gil
>
>
> -----Original Message-----
> *From:* Tamari, Yossi [mailto:]
> *Sent:* Mon, September 23, 2002 10:47
> *To:* 'Gil Tayar';
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> Hi Gil,
>
> I must be misreading the spec, because it seems to me
> that expires is an int number of seconds currently in
> the spec (which may not be the the right way, but that's
> what was decided).
>
> As for scoping to the Producer, can you please explain
> how that works around the need for other scopes (unless
> they are coded into the validationTag)?
>
> Yossi.
>
> -----Original Message-----
> *From:* Gil Tayar [mailto:]
> *Sent:* Monday, September 23, 2002 7:23 AM
> *To:*
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> Good questions.
>
> On the scope question, I would scope it to the
> /Producer/. This is the easiest and works around
> problems with the other scopes.
>
> On the type of time - the validUntil is a
> "date-time" field just like Expires is, and I
> suggest we use the xsd:dateTime type for it (or
> whatever its exact name is). This means that the
> time is an absolute time.
>
> -----Original Message-----
> *From:* Tamari, Yossi [mailto:]
> *Sent:* Thu, September 19, 2002 17:56
> *To:* 'Gil Tayar';
> *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>
> What is the scope of the cached fragments? user?
> session? entity? Should this be explicitly
> returned in the markupResponse or in the
> metadata of the entity, or does the entity
> encode it into the validationTag if it wants to?
>
> Should we return the (absolute) expiration time
> or the (relative) amount of time until
> expiration? on the "expires" field I was for
> expiration time but I was out-voted.
>
> Yossi.
>
>
> -----Original Message-----
> *From:* Gil Tayar
> [mailto:]
> *Sent:* Thursday, September 19, 2002 9:03 AM
> *To:*
> *Subject:* [wsrp-wsia] [I#97] Caching Mechanism
>
> Topic: interface
> Class: Technical
> Title: Caching Mechanism
> Document Section: Interfaces/6.1
> Description:
> I am submitting the following proposition to
> the committee as a proposition for dealing
> with caching of the markup. This proposition
> deals with "Expires"-like methods of
> caching, along with
> "If-Modified-Since/ETags" type of caching. I
> believe it is simple enough to be included
> in the v1.0 spec.
>
> *Caching Proposal*
> [The proposal is described as edits to the spec]
>
> 6.1 Operations [getMarkup]
>
> [instead of expires in markupResponse, add
> the following]
> cacheControl: A data structure, defined in
> Section 11, which includes information which
> CAN be used by the Consumer to cache the
> markup. This structure includes:
> validUntil: The time at which the markup
> is valid. Until that time the Consumer CAN
> use its cache entry instead of calling
> getMarkup. After this time passes, the
> Consumer MAY continue to use this cache
> entry, but only after validating it with a
> getMarkup operation, using the validationTag
> below, if given.
> validationTag: The Consumer MUST store
> this tag along with the markup while the
> markup is valid. This enables the Producer
> to use this tag to invalidate the cache
> entry by sending an invalidationTagPrefix in
> the performInteraction operation. After the
> markup expires, the Consumer CAN send the
> validationTag in the markupResponse to
> indicate that it still has the markup but
> would like to validate it. The Producer
> returns a fault response [TBD] to indicate
> that the markup is still valid, otherwise if
> it returns markup , the Consumer MUST
> invalidate the old markup.
>
> [add to markupContext the following field]
> validationTag: This field CAN be sent to
> indicate that the Consumer has cached markup
> (which was tagged by the Producer with this
> value) and wishes to check whether it is
> still valid. See validationTag in
> markupResponse for more information.
>
> 6.1 Operations [performInteraction]
> [add the following field to interactionResponse]
> invalidationTagPrefix: If the Producer
> returned this value, the Consumer MUST
> expire all markup-s who's validationTag
> begins with this value. The Consumer MUST
> not call getMarkup with these
> invalidationTag-s to validate these expired
> markup-s.
>
> [add these fields to the relevant places in
> section 11]
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Discussion:
>
>
