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


Yossi, your proposal is the best so far.  It provides a good semantical framework for the type of caching we have found useful in our Portal.  It also seems to draw a reasonable line of being "enough" function without getting overly expressive and complex.  However, there are needs (by ourselves and I suspect others) to at times be overly expressive and complex.  Hence we would like to see [more] extensibility built into the mechanism.  I.e. view the semantics you have defined as "base" semantics but allow for extended support/semantics where applicable.

For extensibility, we need the proposal to:

a) Add an extension field in the cacheControl structure to carry additional information
b) Allow extended information to be returned with the invalidationTagPrefix from a processAction
c) define cachingScope in the getMarkup's cacheControl return structure in an extensible manner.  A suggestion is to define cachingScope as a String.  "session", "user", and "producer" would be predefined, well understood scopes.  However, cooperating consumers and producers could additionally use vendor specific scopes.
By adding these to the proposal  we would have both a good basic level/semantic of caching and allow vendors like us to support/express a greater level.  A few specific "extensions" that we think it would be better if the base proposal incorporated directly would be:
a) you can return multiple [invalidation] tags from a processAction.  Tags are still "prefixes", however there is value in returning multiple prefixes to accurately prune a tree whether at a leaf or higher up.

b) you can return multiple tags in a cacheControl structure from getMarkup.  I.e. the validationTag field is a list.  The semantic of this is each tag is a discrete invalidation key for the content returned from this getMarkup.  Supporting this give a producer the flexibility to categorize cache content along different dimensions and invalidate accordingly along a dimension.

c) you can return an urgencyToExpire value along with the invalidation tags from processAction.  This field would express how quickly the cache must attempt the invalidation.  I.e. invalidate these keys but its okay if you are busy to continue serving "stale" data for a given duration.  There is one field/value for the entire list of tags returned.

d) you can return an urgencyToExpire value in the cacheControl structure from the getMarkup. Similar to the function in (c), this directs the cache as to the urgency of invalidating the cache if/when one goes "out of scope" where scope is the cache scope defined by cachingScope.

We strongly urge these "extensions" be considered and added into the proposal as they have good value and would be somewhat clumsy to express in the extension mechanism. However, if that is not the consensus of the group, as long as your proposal carries at least the minimal extensibility defined at the top we would have enough mechanism to express the above function.
    -Mike-

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


Powered by eList eXpress LLC