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
--On August 10, 2005 1:56:05 PM +1000 Eric Scheid [EMAIL PROTECTED] wrote:
Aside: a perfect example of what sense of 'expires' is in the I-D itself...
Network Working Group
Internet-Draft
Expires: January 2, 2006
Especially perfect because the HTTP header does not reflect the
So, you're really looking for entry-level, time-based invalidation, no?
I guess the simplest way to do this would be to dereference the link
and see if you get a 404/410; if you do, you know it's no longer good.
That's not terribly efficient, but OTOH managing metadata in multiple
places
Sorry for taking so long to reply. I have been off on a 700km cycle trip
http://blogs.sun.com/roller/page/bblfish/20050807
I don't really want to spend to much time on the top-X discussion, as
I am
a lot more interested in the feed history itself, but here are some
thoughts
anyway...
On
On 4 Aug 2005, at 06:27, Mark Nottingham wrote:
So, if I read you correctly, it sounds like you have a method
whereby a 'top20' feed wouldn't need history:prev to give the kind
of history that you're thinking of, right?
If that's the case, I'm tempted to just tweak the draft so that
--On August 9, 2005 1:07:29 PM +0200 Henry Story [EMAIL PROTECTED] wrote:
But I would really like some way to specify that the next feed document is an
archive (ie. won't change). This would make it easy for clients to know when
to stop following the links, ie, when they have cought up with
Walter Underwood wrote:
--On August 9, 2005 1:07:29 PM +0200 Henry Story [EMAIL PROTECTED] wrote:
But I would really like some way to specify that the next feed document is an
archive (ie. won't change). This would make it easy for clients to know when
to stop following the links, ie,
On 9 Aug 2005, at 18:32, 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
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
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
Henry Story wrote:
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?
On the
On 09/08/2005, at 4:07 AM, Henry Story wrote:
But I would really like some way to specify that the next feed
document is an archive (ie. won't change). This would make it easy
for clients to know when to stop following the links, ie, when they
have cought up with the changes since they
HTTP isn't a transport protocol, it's a transfer protocol; i.e., the
caching information (and other entity metadata) are *part of* the
entity, not something that's conceptually separate.
The problem with having an abstract or transport-neutral concept
of caching is that it leaves you
On 10/8/05 12:46 PM, James M Snell [EMAIL PROTECTED] 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
Looks good, I think it does need a little bit of prose explaining
First off, let me stress that I am NOT talking about caching scenarios
here... (my use of the terms application layer and transport layer
were an unfortunate mistake on my part that only served to confuse my point)
Let's get away from the multiprotocol question for a bit (it never leads
So, if I read you correctly, it sounds like you have a method whereby
a 'top20' feed wouldn't need history:prev to give the kind of history
that you're thinking of, right?
If that's the case, I'm tempted to just tweak the draft so that
history:stateful is optional if history:prev is
I get the feeling that we should perhaps first list the main types of
history archives, and
then deal with each one separately. I can see 3:
1- The top 20 list: here one wants to move to the previous top
20 list and think of them
as one thing. The link to the next feed is not
Below I think I have worked out how one can in fact have a top20
feed, and
I show how this can be combined without trouble with the
history:next ...
link...
On 29 Jul 2005, at 13:12, Eric Scheid wrote:
On 29/7/05 7:57 PM, Henry Story [EMAIL PROTECTED] wrote:
1- The top 20 list: here
On 29/7/05 11:39 PM, Henry Story [EMAIL PROTECTED] wrote:
Below I think I have worked out how one can in fact have a top20 feed, and I
show how this can be combined without trouble with the history:next ...
link...
On 29 Jul 2005, at 13:12, Eric Scheid wrote:
On 29/7/05 7:57 PM,
On Sat, 2005-07-23 at 09:14 -0700, Mark Nottingham wrote:
Archives *should not* change. I think any librarian will agree with
that.
I very much agree that this is the ideal that should be striven for.
The underlying problem, I think, is that different feeds have
different
On 19/07/2005, at 2:04 AM, Henry Story wrote:
Clearly the archive feed will work best if archive documents, once
completed (containing a
given number of entries) never change. Readers of the archive will
have a simple way to know when
to stop reading: there should never be a need to
Am 21.07.2005 um 16:13 schrieb Mark Nottingham:
On 19/07/2005, at 1:48 AM, Stefan Eissing wrote:
[...]
I have the feeling that clients will need to protect themselves from
servers with almost infinite histories. So a client will probably
offer a XX days into the past, max NN entries
Am 18.07.2005 um 23:21 schrieb Mark Nottingham:
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still
On 18 Jul 2005, at 23:21, Mark Nottingham wrote:
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the
abort condition (e.g. all items on a historical feed are known)
will also do the job. However this
On 19 Jul 2005, at 01:52, A. Pagaltzis wrote:
* Mark Nottingham [EMAIL PROTECTED] [2005-07-18 23:30]:
This is one of the unanswered questions that I left out of
scope. The consumer can examine the previous archive's URI and
decide as to whether it's seen it or not before, and therefore
On Monday, July 18, 2005, at 01:59 AM, Stefan Eissing wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful feed.
As an alternative one could drop fh:stateful and define that an empty
fh:prev (refering to itself) is the last document in a stateful feed.
That would eliminate
On Tuesday, July 19, 2005, at 12:29 PM, Antone Roundy wrote:
On Monday, July 18, 2005, at 01:59 AM, Stefan Eissing wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define that an
empty fh:prev (refering to itself)
to -02;
http://ftp.ietf.org/internet-drafts/draft-nottingham-atompub-
feed-history-02.txt
The most noticeable change in this version is the inclusion of a
namespace URI, to allow implementation.
I don't intend to update it for a while, so as to gather
implementation feedback.
Just
Henry Story wrote:
Sorry I did not participate in the previous discussion for format 00.
I only just
realized this was going on. What is clear is that this is really needed!
I agree with Stefan Eissing's random thought that it may not be a
good idea to use
Atom for a top 10 feed. Atom
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define
that an empty fh:prev (refering to itself) is the last document
in a stateful feed. That would eliminate the
Mark Nottingham wrote:
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define that
an empty fh:prev (refering to itself) is the last document in a
stateful feed.
There is precedence for using atom:link in RSS feeds. see
http://feeds.feedburner.com/ITConversations-EverythingMP3. I really
don't think it's a problem.
Mark Nottingham wrote:
That's what I originally did, but I have a rather strong preference
to make a single syntax work in RSS and
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still means that clients need to check the
first
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also do
the job. However this still means that clients need to check the first
fh:prev document if they know all entries there - if my
On 18/07/2005, at 1:29 PM, Stefan Eissing wrote:
I agree that special URIs are not that great either. Another idea
might be nested elements:
stateful feed: fh:historyfh:prevhttp://example.org/thingie1.1/
fh:prev/fh:history
stateful initial feed: fh:history/
stateless feed:
Am 18.07.2005 um 19:33 schrieb Mark Nottingham:
On 18/07/2005, at 1:29 PM, Stefan Eissing wrote:
I agree that special URIs are not that great either. Another idea
might be nested elements:
stateful feed:
fh:historyfh:prevhttp://example.org/thingie1.1/fh:prev/fh:
history
stateful
Heh... the same questions could be asked about a lot of stuff embedded
in RSS but that's not the issue ;-) ... fh:prev works fine. There
really isn't a strong argument in favor of link. I have my own personal
preferences but those are actually quite irrelevant :-)I'll still
maintain
Am 18.07.2005 um 18:59 schrieb James M Snell:
Mark Nottingham wrote:
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define
that an empty fh:prev (refering to
The Feed History draft has been updated to -02;
http://ftp.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-02.txt
The most noticeable change in this version is the inclusion of a
namespace URI, to allow implementation.
I don't intend to update it for a while, so
39 matches
Mail list logo
