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.
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.
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.
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:
|