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 i
--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 reflec
This is precisely why the expires/max-age needs to operate strictly on
the entry level. The expires/max-age elements may appear on the feed
level but it actually only applies to the entries within that feed.
Going back and reading my draft, I see that I screwed up and didn't
indicate that p
There is an interesting problem of how this interacts with the
history tag.
If you set an a 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
Eric Scheid wrote:
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
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
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 ex
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
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
wo
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 l
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
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
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 and
extension mysel
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
and
--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
> and extension myself and was getting ready to
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, w
--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
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
hist
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 2
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 prese
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
> link...
>
>
> On 29 Jul 2005, at 13:12, Eric Scheid wrote:
>
>> On 29/7/05 7:57 PM, "Henry
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
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 one wants to m
On 29/7/05 9:12 PM, "Eric Scheid" <[EMAIL PROTECTED]> wrote:
> It's conceivable they could also provide a feed for each publication
> pointing to the table of contents feeds of each issue. That is, a feed with
> an entry for each issue.
There is another issue with the idea individual Atom Feed D
On 29/7/05 7:57 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> 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 meant to be
> additive. Each feed is to be seen as a whole. I have a little trouble still
> thi
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 mea
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 s
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 re-read
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 setti
On 19/07/2005, at 1:48 AM, Stefan Eissing wrote:
Let's say CNN goes stateful, how would a client handle a history
which soon consists of thousands of entries. How would a server
best offer such a history to avoid clients retrieving it over and
over again. Probably nobody has a good idea
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)
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 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
a
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 sti
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
* 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
> avoid fetching it if it already has seen it.
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 tha
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 it
Not a problem, as such, but I don't see any benefit to reuse. It also
begs the question of what an atom element in a non-Atom document
means, how it's processed, etc.
On 18/07/2005, at 1:03 PM, James M Snell wrote:
There is precedence for using atom:link in RSS feeds. see http://
feeds.
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: http://example.org/thingie1.1fh:prev>
stateful initial feed:
stateless feed:
Hmm. My thinking was that allowing stateful to be
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:
http://example.org/thingie1.1history>
stateful initial feed:
stateless feed:
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 u
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 fh
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 A
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. T
That's what I originally did, but I have a rather strong preference
to make a single syntax work in RSS and Atom. atom:link is
(naturally) specific to Atom, and people will balk at using the atom
namespace in RSS feeds.
That's not to say that every Atom extension should be usable in RSS,
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 ca
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
:
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 as
Stefan Eissing wrote:
Am 16.07.2005 um 17:57 schrieb Mark Nottingham:
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
Am 16.07.2005 um 17:57 schrieb Mark Nottingham:
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
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
51 matches
Mail list logo
