[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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.
Powered by eList eXpress LLC