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