[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism
Gil - does the following wording catch the spirit of your and Yossi's
proposal:
1.1.1 CacheControl
The CacheControl structure contains a set of fields needed for the entity
to managed cached markup fragments.
CacheControl
[O] long validityPeriod
[O] String[] cacheCtx
Members:
· validityPeriod: Number of seconds the markup fragment referenced by
this cache control entry remains valid. If this value is less than zero the
producer indicates that the fragment will never expire
· cacheCtx: Array of CacheHint constants that define what information
of the input space for getMarkup the generated fragment depends on. The
consumer can use this information to check prior to a call to getMarkup if
it may get content from the fragment cache or needs to retrieve an updated
fragment based on updated input data. The following constants are defined:
a. CACHE_USER: parts of the userContext have been used to generate the
markup. The consumer needs to retrieve new content if the userContext
changes between requests.
b. CACHE_REGISTRATION: parts of the registrationContext have been used
to generate the markup. The consumer needs to retrieve new content if the
registrationContext changes between requests.
c. CACHE_MARKUP_PARAMS: parts of the markupParams have been used to
generate the markup. The consumer needs to retrieve new content if the
markupParams changes between requests. This flags only needs to be set if
parts of the markup parameters other than the ones listed in Section ??
have been changed.
MarkupResponse
[O] ResponseContext response
[O] String markup
[O] String preferredTitle
[O] boolean needsUrlRewriting
[O] Property[] extensions
[O] CacheControl cacheCtx
1.1.1 Caching of markup fragments
For performance reasons the Consumer might need to cache the output of
getMarkup across a series of requests. The Producer passes information
about the cachability of the markup fragment returned by getMarkup in the
cacheCtx structure of MarkupResponse. The Consumer can defer from this
information when it may cache markup and when the cached markup needs to
be invalidated and updated by a new call to getMarkup.
1.1.1.1 Cachability
Whenever the cacheCtx structure of markupResponse is filled in the
Consumer MAY cache the markup fragment. It must then follow the WSRP
invalidation policies to keep the cache up-to-date (see next section).
If the cacheCtx structure is missing the Consumer MUST not cache the
markup fragment.
1.1.1.2 Invalidation
The Consumer knows when to invalidate its cached fragments from one of
the following mechanisms:
· Time based expiry: The Consumer MUST expire a markup fragment after
the validityPeriod returned in the cacheCtx of markup response has timed
out, counting from the point in time when the getMarkup request has
returned. If the validityPeriod is less than zero the fragment will never
time out. If the validityPeriod equals zero the fragment MUST NOT be
cached.
· Hint based expiry: The Producer MAY return hints to the Consumer on
what input parameters the generated markup depends on (see definition of
the CacheControl structure). The Consumer MAY use these hints to invalidate
the cached fragments if the designated input parameters changed since the
request that resulted in the last cache miss.
· State based expiry: The Consumer MUST expire the markup fragment if
parts of the consumer managed state of the entity changed. This includes
changes in the window state, portlet state, navigationalState and
entityState. The CACHE_MARKUP_PARAMS hint does not refer to changes in one
of these attributes.
· Action based expiry: After processing performInteraction all cache
entries that belong to an entity need to be invalidated.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 09/26/2002 08:38 |
| | AM |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-wsia@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp-wsia] [I#97] Caching Mechanism |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------------|
Carsten,
I definitely agree - a full algorithm would be complicated. But what Yossi
suggested is, in essence, a very simple approach to this problem that will
solve 90% of the "scoping" of the cache entries issues. It's a good first
approach.
I propose going through with it. I can easily add something to my proposal.
Gil
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tue, September 24, 2002 18:22
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
<Gil.Tayar@webcollage.com>, wsrp-wsia@lists.oasis-open.org |
| 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
----------------------------------------------------------------
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