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

From
Tamari, Yossi <>
Date
2002-09-19T14:56:58+00:00
ID
5199D0E7CA63D511BB6F0008C75DAD14036535A7@dewdfx2e
Thread
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: