There is an interesting problem of how this interacts with the
history tag.
If you set an a feed
<feed>
<expires>...</expires>
<entry></entry>
<entry></entry>
</feed>
then what are you setting it on? Well not the document, clearly, as
you have
pointed out since HTTP headers deal with that. So it must be on the
feed. And
of course a feed is identified by its id.
Now we have to make sure we avoid contradictions where different feed
documents
describing the same feed state that the feed has different expiry dates.
Eg:
----the main feed----------
<feed>
<expires>August 25 2006</expires>
<id>tag:example.com,2000/feed1</id>
<entry></entry>
<entry></entry>
<history:previous>http://example.com/archive1</history:previous>
</feed>
---------------------------
The above is a partial description of the feed tag:example.com,2000/
feed1
The history:previous link points to another document that gives
us more information about that feed.
---the archive feed--------
<feed>
<expires>August 15 2006</expires>
<id>tag:example.com,2000/feed1</id>
<entry></entry>
<entry></entry>
<history:previous>http://example.com/archive2</history:previous>
</feed>
---------------------------
Now of course we have a feed id with two expiry dates. Which one is
correct?
In graph terms we end up with something like this:
tag:example.com,2000
|----expires------>August 25 2006
|----expires------>August 15 2006
|----entry-------->...
|----entry-------->...
|----entry-------->...
|----entry-------->...
One has the feeling that the expires relation should be functional,
ie have
only one value.
This makes me think again that for what I was looking for (that the
document
in history:previous not change, so that one can work out when to stop
fetching
documents) can in fact be entirely be taken care of by the http
expiry dates and
cache control mechanism. Of course if this is so, I think it should
be noted
clearly in the history spec. ((btw. Is it easy to set expiry dates
for documents served
by apache?))
Henry Story
On 10 Aug 2005, at 04:46, James M Snell wrote:
This is fairly quick and off-the-cuff, but here's an initial draft
to get the ball rolling..
http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt
- James
Henry Story wrote:
To answer my own question
[[
Interesting... but why have a limit of one year? For archives, I
would like a limit of
forever.
]]
I found the following in the HTTP spec
[[
To mark a response as "never expires," an origin server sends an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.
]]
(though that still does not explain why.)
Now I am wondering if the http mechanism is perhaps all that is
needed
for what I want with the unchanging archives. If it is then
perhaps this
could be explained in the Feed History RFC. Or are there other
reasons to
add and "expires" tag to the document itself?
Henry Story
On 9 Aug 2005, at 19:09, James M Snell wrote:
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.
