RE: [wsrp-wsia] [I#97] Caching Mechanism

["Tamari, Yossi" <yossi.tamari@sap.com>]

Hi Alejandro,

I tried to keep it relatively simple, since otherwise I don't think there was any chance to out it in 1.0.
If we add locale/markupType/mode/navigational-state to the cachingScope, we will probably have to make it a vector since these things are orthogonal to the original enumeration of scopes. It seems to me like in 99% of the cases changing the local/markupType/mode means that a new cache instance needs to be created. Also, if we added them, we would also have to add something like "this markup is valid for modes 1 and 2 but not for mode 3" semantics (I don't think you can use cached content for edit mode...), as you also implied in 3, and this also applies to markupType and mode.

Regarding navigationalState, I think the specific parts of the navigationalState determine the caching behavior, and this should be implemented through the invalidation tag.

	Yossi.  

-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: Thursday, October 24, 2002 5:07 AM
Cc: wsrp-wsia@lists.oasis-open.org
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>
> 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>