Walter Underwood wrote:
--On August 9, 2005 9:28:52 AM -0700 James M Snell <[EMAIL PROTECTED]> wrote:
I made some proposals for cache control info (expires and max-age).
That might work for this.
I missed these proposals. I've been giving some thought to an <expires /> and
<max-age /> extension myself and was getting ready to write up a draft. Expires is a
simple date construct specifying the exact moment (inclusive) that the entry/feed expires.
Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the
moment specified by atom:updated when then entry/feed expires. The two cannot appear
together within a single entry/feed and follows the same basic
rules as atom:author elements.
Here it is: <http://www.intertwingly.net/wiki/pie/PaceCaching>
The expires and max-age elements look fine. I hesitate at bringing in a
caching discussion. I'm much more comfortable leaving the definition of
caching rules to the protocol level (HTTP) rather than the format
extension level. Namely, I don't want to have to go into defining rules
for how HTTP headers that affect caching interact with the expires and
max-age elements... IMHO, there is simply no value in that.
The expires and max-age extension elements affect the feed / entry on
the application level not the document level. HTTP caching works on the
document level.
Adding max-age also means defining IntegerConstruct and disallowing
white space around it. Formerly, it was OK as a text construct, but
the white space issues change that.
This is easy enough.
Also, we should decide whether cache information is part of the signature.
I can see arguments either way.
-1. let's let caching be handled by the transport layer.
- James
