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

My understanding of the F2F dicussion about caching was something like 
this (wrote it up during the discussion):

.Portlet metadata indicates what elements of the request are to be
  used as cache keys:
   * Markup
   * Locale
   * Navigational state
   * SessionID
.Consumer uses (above) metadata to create consumer-key
.Producer returns producer-key & expiration with getMarkup
.Producer-key should be created using a hierachical namespace that
  allows later batch invalidation based on a prefix of the producer-key
.Consumer caches the fragment with two access keys (consumer-key,
.Consumer discards cache entry on expiration
.Consumer queries cache using consumer-key on new requests to the
.On perform action producer may return producer-key prefix to
  invalidate cache entries (the producer-keys are opaque to the
  consumer, their only purpose is cache invalidation upon actions)

Tamari, Yossi wrote:
> I still don't see how option 1 can work, but I'd be happy to see a proposal.
> If we want to go for simplicity (I do...) we can add another return 
> parameter parallel to the validationTag, that defines the cachingScope. 
> It can be an enumeration, where 1 means user scope, and 2 means producer 
> scope. These are the two scopes which I see as a must.
> Additionally we can add cachingScope 0 which means session, without 
> which producer may have to mark session dependent content as uncachable.
> Another optional scope is the entity scope, but I don't see any use case 
> for separating this from the producer scope.
>     Yossi.
>     -----Original Message-----
>     *From:* Gil Tayar [mailto:Gil.Tayar@webcollage.com]
>     *Sent:* Tuesday, September 24, 2002 6:40 AM
>     *To:* wsrp-wsia@lists.oasis-open.org
>     *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>     Now I get you.
>     Actually, you're right. I forgot about that part.
>     We can approach it two ways -
>     1. The way you suggested - the Producer encodes the parameters of
>     the difference into validationTag. I'm not sure why this wouldn't work.
>     2. Draft something (as discussed in the F2F) about the portlet
>     defining which parameters of the request to getMarkup are the key to
>     the cache entry.
>     I am, for simplicity, inclined for the first proposal, but am ready
>     to draft the second one. What is the opinion of the TC?
>     Gil
>         -----Original Message-----
>         *From:* Tamari, Yossi [mailto:yossi.tamari@sap.com]
>         *Sent:* Mon, September 23, 2002 13:53
>         *To:* 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
>         *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>         The need for different scopes of caching:
>         Say I have a portlet that is cached by the consumer, scoped to
>         the producer. Say this portlet is capable of personalization
>         through the edit mode.
>         First user U1 asks for this portlet and gets his personalized
>         content. Then user U2 asks for the same portlet, but his
>         personalization info is different. He will get the cached
>         portlet with U1's personalization! Now assume user U1 also went
>         into edit mode, got the edit page with his current settings, and
>         pressed cancel. The cache was not invalidated. Now U2 goes into
>         edit mode - he will get the cached edit page with U1's choices
>         as his choices!
>         This demonstrates the need for user-scoped caching.
>         The need for session scoped caching is demonstrated by: a user
>         opens a portal page, a session is created for a portlet in this
>         page, the user navigates in this portlet (actions), thereby
>         changing the session information. He ends up with page #4 (of
>         the portlet), and some session information that is related to
>         how he got to this page. page #4 is cached. Now he closes his
>         browser and open a new one. The session is killed. He navigates
>         to page #4 through the cache, never actually going to the
>         producer. Then he navigates to page #5, forcing a WSRP request
>         to the producer. However, the producer can't service this
>         request - it needs the information that was gathered in pages 1-4.
>         It is possible to create a portlet that will not have this
>         problem, by encoding all information in the URL, but I don't
>         think it is reasonable to demand this.
>         In the F2F discussion about caching we suggested using, in
>         addition to the mechanism you suggest, all the parameters of the
>         action as keys to the cache, and allowing a portlet to define
>         which parameters can be ignored. I was missing this in your
>         suggestion. One way to implement this is by telling the producer
>         it needs to encode these parameters into the validationTag, but
>         unless the consumer knows the encoding algorithm it does not
>         really work
>             Yossi.
>             -----Original Message-----
>             *From:* Gil Tayar [mailto:Gil.Tayar@webcollage.com]
>             *Sent:* Monday, September 23, 2002 12:44 PM
>             *To:* Tamari, Yossi; wsrp-wsia@lists.oasis-open.org
>             *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>             The spec says that the "expires" is a placeholder for a real
>             caching mechanism. My proposal was intended to replace it.   
>             I didn't say it works around the need for other scopes (I'm
>             not certain what those needs are). I said that it doesn't
>             look to have problems that the other scopes /do/ have.
>             Gil
>                 -----Original Message-----
>                 *From:* Tamari, Yossi [mailto:yossi.tamari@sap.com]
>                 *Sent:* Mon, September 23, 2002 10:47
>                 *To:* 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
>                 *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>                 Hi Gil,
>                 I must be misreading the spec, because it seems to me
>                 that expires is an int number of seconds currently in
>                 the spec (which may not be the the right way, but that's
>                 what was decided).
>                 As for scoping to the Producer, can you please explain
>                 how that works around the need for other scopes (unless
>                 they are coded into the validationTag)?
>                     Yossi.
>                     -----Original Message-----
>                     *From:* Gil Tayar [mailto:Gil.Tayar@webcollage.com]
>                     *Sent:* Monday, September 23, 2002 7:23 AM
>                     *To:* wsrp-wsia@lists.oasis-open.org
>                     *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>                     Good questions.
>                     On the scope question, I would scope it to the
>                     /Producer/. This is the easiest and works around
>                     problems with the other scopes.
>                     On the type of time - the validUntil is a
>                     "date-time" field just like Expires is, and I
>                     suggest we use the xsd:dateTime type for it (or
>                     whatever its exact name is). This means that the
>                     time is an absolute time.
>                         -----Original Message-----
>                         *From:* Tamari, Yossi [mailto:yossi.tamari@sap.com]
>                         *Sent:* Thu, September 19, 2002 17:56
>                         *To:* 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
>                         *Subject:* RE: [wsrp-wsia] [I#97] Caching Mechanism
>                         What is the scope of the cached fragments? user?
>                         session? entity? Should this be explicitly
>                         returned in the markupResponse or in the
>                         metadata of the entity, or does the entity
>                         encode it into the validationTag if it wants to?
>                         Should we return the (absolute) expiration time
>                         or the (relative) amount of time until
>                         expiration? on the "expires" field I was for
>                         expiration time but I was out-voted.
>                             Yossi.
>                             -----Original Message-----
>                             *From:* Gil Tayar
>                             [mailto:Gil.Tayar@webcollage.com]
>                             *Sent:* Thursday, September 19, 2002 9:03 AM
>                             *To:* wsrp-wsia@lists.oasis-open.org
>                             *Subject:* [wsrp-wsia] [I#97] Caching Mechanism
>                             Topic: interface
>                             Class:  Technical
>                             Title: Caching Mechanism
>                             Document Section: Interfaces/6.1
>                             Description:
>                             I am submitting the following proposition to
>                             the committee as a proposition for dealing
>                             with caching of the markup. This proposition
>                             deals with "Expires"-like methods of
>                             caching, along with
>                             "If-Modified-Since/ETags" type of caching. I
>                             believe it is simple enough to be included
>                             in the v1.0 spec.
>                             *Caching Proposal*
>                             [The proposal is described as edits to the spec]
>                             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:
>                                 validUntil: The time at which the markup
>                             is valid. Until that time the Consumer CAN
>                             use its cache entry instead of calling
>                             getMarkup. After this time passes, the
>                             Consumer MAY continue to use this cache
>                             entry, but only after validating it with a
>                             getMarkup operation, using the validationTag
>                             below, if given.
>                                 validationTag: The Consumer MUST store
>                             this tag along with the markup while the
>                             markup is valid. 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.
>                             [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.
>                             [add these fields to the relevant places in
>                             section 11]
>                             %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>                             Discussion:

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

Powered by eList eXpress LLC