Good point.
OK, so I'll change the proposition so that expires is an integer
defining expiration time (in seconds). Anybody opposing
that?
Gil
-----Original Message-----
From: Sasha Aickin
[mailto:]
Sent: Tue, September 24, 2002
02:59
To: Michael Freedman;
Subject: RE: [wsrp-wsia] [I#97]
Caching Mechanism
I
believe that HTTP switched to using an integer based expiry (i.e. max-age)
mechanism (rather than date) to get around the problem of unsynchronized
clocks. If you send an absolute time (in an absolute time zone), you are
depending on the clocks on the client and server being in sync. A lot of
applications want to cache content for just a few minutes, which is well
within the possible error of clock synchronicity.
If
for some reason we really want to use an absolute date for expiry, the server
would have to send back its current date so that the client can calculate how
long the content should remain fresh. We would also have to be explicit
that the expiry date was to be calculated relative to the server's returned
current date.
Cheers,
Sasha.
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Monday, September 23,
2002 4:51 PM
To:
Subject:
Re: [wsrp-wsia] [I#97] Caching Mechanism
If I recall
correctly, "expires" refers to the refHandle not the content. I.e. it
defines the length of time the refHandle will be valid for between
requests. As such it is a duration -- which is reset per
request. Hence its definition as an "int". Content expiration
isn't affected by access, hence using an absolute time can be
considered. Using a duration, however, would also be valid. We
need to decide which is more common/convenient for our developers.
I.e. Is it more common/easier to say this content expires in 30 minutes or
to dynamically compute when 30 minutes from now is (in some absolute
timezone form)?
-Mike-
"Tamari, Yossi" wrote:
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:
interfaceClass: TechnicalTitle: Caching MechanismDocument Section: Interfaces/6.1Description: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:
