RE: [wsrp-wsia] [I#97] Caching Mechanism

In our 
caching mechanism discussions there were 3 axes we discussed for the 
invalidation scheme:

1. 
time - which everybody agrees on.

2. 
scope (session/user/locale/...) - which was missing from Gil's initial proposal 
bellow, but is now in the 0.7 spec draft.

3. 
producer knowledge - which was the heart of Gil's proposal, and is based on the 
idea that only the producer knows which actions actually effect which markup 
fragments, so the producer should be telling the consumer which cache elements 
need to be invalidated as a result. This axis is missing from the spec draft 
0.7, based on Carsten's write-up, probably for reasons of 
simplicity.

 

I 
would like to try and incorporate the scope axis into Gil's proposal, in order 
to create a simple mechanism that has all 3 axes.

In 
addition, I would like to go in the direction that all these are hints. If the 
consumer ignores them, it may end up showing invalid markup, but that is its 
responsibility (for example this can be useful when working offline), or it may 
end up throwing away valid markup, loosing some caching 
abilities.

 

So 
here goes:

 

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:

    validityPeriod: 
The number of seconds 
during which the markup is 
valid. During that time the Consumer CAN use its cache 
entry instead of calling getMarkup.

    
validationTag: The 
Consumer SHOULD store this tag along 
with the markup while the markup is cached. 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.

    cachingScope: This is an 
enumeration field used by the producer to tell the consumer what is the caching 
scope of the markup. Possible values for this field 
are:

1 - session. The markup is invalid 
outside the scope of the current client 
session.

2 - user. The markup is only valid for 
this user, regardless of his session.

3 - producer. All requests for this 
resource can be served by one valid cached 
markup.

While this is not an explicit part of 
the protocol, The consumer SHOULD also not use a cached markup in any scope that 
was generated for a different 
locale/markupType/mode.

 

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

 

Hopefully this proposal gives good coverage of 
different caching scenarios for consumers/producers that make full use of it, 
while degrading gracefully for those that make use of only some of the elements. 
For example, many producers will probably not use the validation tag, and some 
consumers will probably only do per-user, per-URL caching, but they can still 
make use of the more basic parameters (like validity period). It may be a good 
idea to also add some metadata describing these capabilities in the producer and 
consumer metadata.

 

    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: