OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, September 19, 2002 9:03 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#97] Caching Mechanism

Topic: interface
Class:  Technical
Title: Caching Mechanism
Document Section: Interfaces/6.1
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]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC