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.
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
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.
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
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.
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.
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.
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:
|