[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, producer-key) .Consumer discards cache entry on expiration .Consumer queries cache using consumer-key on new requests to the portlet .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