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:
