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


Title: RE: [wsrp-wsia] [I#97] Caching Mechanism
Thanks Yossi,

You just clarified that for me. It sounds to me like you understood what I was getting at quite well. I was concerned about the Producer being allowed or even required to persist that information. It is an area that I am concerned with and I assumed wrongly that we were dealing with producer being allowed or expected to use the U1 profile in your example. Sorry for the misunderstanding. I will endeavor to stay current better than I have. I'm stretched a bit thin, timewise, and there is a lot to keep up with.

Ciao,
Rex

At 4:08 PM +0200 9/24/02, Tamari, Yossi wrote:
Hi Rex,
 
I'm still unclear as to what you mean. The caching we are talking about here is done by the consumer, not the producer. This means the portal is caching pages for its users. This is already done today by most (if not all) portals). We are not discussing caching by the producer. We do not need to put it in the spec, but I don't see any way to prevent producers from persisting personal user information (whether I like it or not).
 
    Yossi.
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Tuesday, September 24, 2002 4:27 PM
To: Gil Tayar; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism

Hi Gil,

I agree that caching is important, I'm just not sure it is wise in this version, at least not to the extent that Yossi was discussing. Also caching is different than archiving or saving personalization information for later use in a database, and I didn't consider that. As long as it is easy to retroactively require that personal information be destroyed after a single use without explicit, item by item, permission from the end user whose information is being handled, it shouldn't turn into a bottleneck later. I haven't thought about what kind of mechanism that might be or how to do it. I know bots could be constructed that end users could activate when closing down their connection to a web service provider which would verify if the information had been destroyed, or at least check to see that the web server log showed that, so I suppose a notification of some sort upon the destruction of the session might be worth considering, but not for this version certainly.

Ciao,
Rex


At 6:35 AM +0300 9/24/02, Gil Tayar wrote:
Rex,
it was the decision in the F2F to bring a simple proposition to the table. That is what I am doing. It may be rejected, but nonetheless, it was the concensus that caching is very important.
 
Gil
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Mon, September 23, 2002 15:59
To: Tamari, Yossi; 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism

Is this something that the spec needs to address?

Just a heads up, but, user information is ultimately going to be protected against copying anywhere except into a file for that particular user that must be destroyed after any single use without the specific itemized and specialized permission of the user, so you won't have this particular problem.

This WILL be a scalability problem, but it certainly won't be confined to Web Services. Now in the case of corporate portals with special permissions required of and by its employees, this could become an issue, but that is one for which our TCs need to liaise with HR-XML.org and the Web Security Standards groups. to ensure legal conformance and interoperability. The one thing I can say coming from the HumanMarkup TC is that this issue won't be dealt with in any kind of official specification submission until this time next year at the earliest.

I don't think this particular kind of caching should be in the first version, and probably shouldn't be formalized until after the other standards groups do their work. As for larger caching issues, I think this tendency toward particularization on micro-issues, which this example only typifies, is a very bad idea.


I don't know about all of you, but I really don't want to be revising endlessly to get back into conformance with other specifications in v.2.0.6, 2.0.7, etc., ad infinitum.

I bring this up here, but it applies across the board.

Ciao,
Rex

At 12:52 PM +0200 9/23/02, Tamari, Yossi wrote:
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:

 


--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


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


Powered by eList eXpress LLC