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:]
Sent: Monday, September 23, 2002
7:23 AM
To:
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:]
Sent: Thu, September 19, 2002
17:56
To: 'Gil Tayar';
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:]
Sent: Thursday, September 19,
2002 9:03 AM
To:
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:
