[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [I#97] Caching Mechanism
It looks good. A few questions: 1. Why locale/markupType/mode are not valid values for the cachingScope? 2. Shouldn't navigational state be allowed as part of the cachingScope? 3. Would be possible the use of wildcards. For example, indicating * for locale to mean that the same content is to be used fo all locales? Alejandro Gil Tayar wrote: > Caching has long been forgotten in these days of heated discussions on > initEnvironment and groupId :-). I would like to return and discuss it. > > There are two proposals on the table. One of them is defined in the v0.8 > spec, and the other is a mechanism proposed by myself and extended by > Yossi and Mike. Is anybody interested in pursuing this mechanism, or > should we just leave the current one (defined in the spec)as it is? The > main difference between the two is that the mechanism in the draft only > includes expiration semantics, but does not include > validation/invalidation semantics. Since most Web apps use > validation/invalidation and not expiration semantics (because usually > expiration time is never well defined for most apps), I believe the > validation/invalidation to be important. The proposal (copied below), > attempts to address this. > > Gil > P.S. For reference, here is the proposal (without Mike's extensions, but > with Yossi's) > > 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. > > -----Original Message----- > From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] > Sent: Wed, October 09, 2002 06:56 > To: wsrp-wsia@lists.oasis-open.org > Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism > > > I totally agree with Rich's comments on Mike's email. The first proposal > (array of invalidationTagPrefixes) is just a simple extension. No questions. > The others raise some questions, and invalidate the concept of a "simple" > caching mechanism. > > Proposal: incorporate Yossi's extension, albeit using strings and not > numbers, add an extension mechanism as per Mike's proposal, and change the > returned invalidationPrefix to be an array of such, as per Mike's proposal. > > -----Original Message----- > From: Rich Thompson [mailto:richt2@us.ibm.com] > Sent: Mon, October 07, 2002 21:08 > To: wsrp-wsia@lists.oasis-open.org > Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism > > > > > > > > I would note that as Carsten's proposal was incorporated in v0.7 that the > standard extensibility was added to CacheControl. > > I would agree that we are using string arrays (maximizes interoperability) > rather than enums throughout the protocol. > > On the first (b) comment, are you proposing there be a structure for the > invalidationTagPrefix or could this just use the fact the > InteractionResponse structure is already extensible? > > From Yossi's original proposal, I would agree that the invalidation > information in InteractionResponse would be better as an array. While it > often would often be used with a size of one, this gives significant power > to the entity at minimal cost to the Consumer. > > The later three proposed extensions are quite specific to how a cache might > be implemented. The extensibility of the data objects certainly would allow > this information to be carried between end-points that > understand/support/exploit it. > > More fundamentally, are we interested in getting the validationTag concept > and its related semantic implications on the various operations into v1? > > > > > > "Tamari, Yossi" > > <yossi.tamari@sap To: > wsrp-wsia@lists.oasis-open.org > .com> cc: > > Subject: RE: [wsrp-wsia] > [I#97] Caching Mechanism > 10/07/2002 02:37 > > PM > > > > > > > > > Hi Mike, > > I agree that my proposal missed the necessary extensibility properties. > They should be added to all relevant objects. > I do not see a difference between enumeration and string in your first c. > Both can be extended. We seem to be using strings with predefined constants > elsewhere in the spec, so I agree with this remark as well. > I don't think we should add the 4 extensions that you offered (especially > the later two), because they seem to cross the line between > simple-in-a-complex-way to complex-squared, and between generic to > vendor-specific. > > Yossi. > -----Original Message----- > From: MICHAEL.FREEDMAN [mailto:MICHAEL.FREEDMAN@oracle.com] > Sent: Monday, October 07, 2002 6:04 PM > To: wsrp-wsia@lists.oasis-open.org > 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- > > > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC