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