[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Hi Carsten,
If I understand correctly, what you are proposing is caching per session (since sessionID is one of the parameters to performInteraction/getMarkup). I don't think this kind of caching is what we are looking for. I have already made, somewhere else in this thread a proposal that is quite simple, and I believe, much more useful. So, from my point of view we should either go for simplicity (with something like my proposal), or go for full functionality (with something like we discussed in the F2F).
Can we raise this issue for discussion next Thursday? (or this Thursday...)
Yossi.
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tuesday, September 24, 2002 6:22 PM
To: Tamari, Yossi
Cc: Gil Tayar; 'Rex Brooks'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Yossi - I completely agree that for an optimal performance there must be a
way for the producer to generate a cache key from all the input parameters
and to let the consumer know how this key was generated. This way the
consumer can determin when to request new markup or when to use the cached
one.
Hoewever a definition of such a key generation algorithm will be quite
difficult and I wonder if we can agree upon one in v1.0 of the spec.
The current proposal by Gil would correspond to a key generation algorithm
that uses the full input space for the key. So it does not need to
explicitly pass this key but can imply it. Of course this is not as
efficient as it could be (the cache size will be to large), but it is a
first step in the right direction ;-)
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | "Tamari, Yossi" |
| | <yossi.tamari@sap|
| | .com> |
| | |
| | 09/24/2002 04:08 |
| | PM |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'Rex Brooks'" <rexb@starbourne.com>, Gil Tayar <[email protected]>, [email protected] |
| cc: |
| Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------------|
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC