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


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