If you use URIs like
http://example.com/feed?start=5num=10
changing the directionality of next and previous will not make
what you're doing compatible with feed history.
Such URIs have a much more fundamental problem -- they don't refer to
a stable set of entries, and therefore only act
* David Powell [EMAIL PROTECTED] [2006-05-03 11:20]:
Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote:
Such URIs have a much more fundamental problem -- they don't
refer to a stable set of entries, and therefore only act as a
snapshot of the *current* feed, chopped up into
(ot for the last thread)
Hi Mark,
I've just specced out an app that uses FH and this idea of an archived
feed hadn't quite come across to me as safe - I had some what ifs
about server resets that affected the feed.
However, the URL:
http://example.com/feed?start=5num=10
nails that
+1, I'd also highly recommend introducing an archive link relation
that can be used to cleanly separate paged feed documents used for state
reconstruction from paged feed documents used for other purposes (e.g.
searching)
===
Attribute Value: archive
Description: A URI that, when
I had this already:
Archive document refers to a feed document that is archived; i.e.,
the set of entries inside it does not change over time. Entries
within an archive MAY themselves change, however.
but if this is catching people by surprise, it obviously isn't
prominent enough.
Any extension that uses previous and next has to account for the
stablity of the underlying resources; if you use *any* paging
application and the set of entries in previous and next changes
over time, you're going to potentially end up with a reconstructed
feed in inconsistent state.
Mark Nottingham [EMAIL PROTECTED] wrote:
Can you expand upon being more precise about exactly what is needed?
I don't have time to go into very much detail right now, but basically
it's about what people are calling 'stable urls' in another part of this
thread.
The draft calls feeds where
Mark Nottingham [EMAIL PROTECTED] wrote:
On 2006/05/01, at 12:55 AM, James M Snell wrote:
As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed History.
Please describe the scenario where you'd want that to happen -- show
the feed.
I don't use APP, but this feed
On 2006/05/01, at 12:55 AM, James M Snell wrote:
Eric Scheid wrote:
I thought OpenSearch results are not sorted by chronological age
at all, but
instead by relevance? Using next with OpenSearch makes sense in
that
context. Using previous for stepping back thru time in a data store
Peter,
Can you expand upon being more precise about exactly what is needed?
On 2006/05/01, at 3:16 AM, Peter Robinson wrote:
Mark Nottingham [EMAIL PROTECTED] wrote:
One thing I did notice -- you're using URLs like this for your
archives:
Mark Nottingham wrote:
[snip]
As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed History.
Please describe the scenario where you'd want that to happen -- show the
feed.
The feed(s) are part of our open activities implementation and are
available via our APP interop
On 1/5/06 2:25 PM, James M Snell [EMAIL PROTECTED] wrote:
While I'm sure the other James may have his own particular set of
issues, the one pain point for me with the history spec is the use of
the previous link to point back in time. This runs counter to the use
of the previous link in
Eric Scheid wrote:
On 1/5/06 2:25 PM, James M Snell [EMAIL PROTECTED] wrote:
While I'm sure the other James may have his own particular set of
issues, the one pain point for me with the history spec is the use of
the previous link to point back in time. This runs counter to the use
of
On 1/5/06 5:55 PM, James M Snell [EMAIL PROTECTED] wrote:
That said, however, we end up with a
problem when we have one spec that says next points backwards in time
(APP), one spec that says next points forwards in time (feed history)
and one spec that says next is just another page of
Mark Nottingham [EMAIL PROTECTED] wrote:
One thing I did notice -- you're using URLs like this for your archives:
http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2amp;count=10
Are they really permanent? If they're relative to the current state
of the feed (i.e., the
James M Snell [EMAIL PROTECTED] wrote:
While I'm sure the other James may have his own particular set of
issues, the one pain point for me with the history spec is the use of
the previous link to point back in time. This runs counter to the use
of the previous link in both OpenSearch, APP
Yes, the paging in APP is a problem (one I've been largely ignoring up
to this point in our own implementation). There is no way of reliably
and efficiently reconstructing the entire feed history.
- James
Eric Scheid wrote:
On 1/5/06 5:55 PM, James M Snell [EMAIL PROTECTED] wrote:
That
Mark,
Right now, the subscription feed uses previous to point to the archive
feeds. Perhaps a better approach would be to to have an archive link
relation that points to the first of a distinct set of archive feeds.
Also, remove the temporal semantics from the the previous link and
require that
James M Snell wrote:
Right now, the subscription feed uses previous to point to the archive
feeds. Perhaps a better approach would be to to have an archive link
relation that points to the first of a distinct set of archive feeds.
If I have to add yet another algorithm for paging support in
Did you find that algorithm wrong, too hard to understand/implement,
or did you just do a different take on it? Does the approach that you
took end up having the same result?
Any suggestions on how to better document it appreciated.
Cheers,
On 2006/04/26, at 8:35 PM, James Holderness
I ran it through my demo implementation for Feed History:
http://www.mnot.net/rss/history/feed_history.py
and it worked fine (after I fixed a bug -- thanks!).
To use that, just download the .py and run it on the command line
like this:
./feed_history.py [filename] [url]
where filename is
Mark Nottingham wrote:
Also, if a client doesn't visit for a long time, it will see
http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2amp;count=10
and assume it already has all of the entries in it, because it's fetched
that URI before.
Yeah. That's what I was worried
Mark,
While I'm sure the other James may have his own particular set of
issues, the one pain point for me with the history spec is the use of
the previous link to point back in time. This runs counter to the use
of the previous link in both OpenSearch, APP and Gdata. It would be
excellent if
We just deployed support
for [EMAIL PROTECTED]"previous" et al. for AOL Journals. If anyone has a
client that makes use of these links, please let me know, I'd love to
see if there are any interoperability problems.
Example Atom feed:
Just ran it through my parser impl. The paging works great. However, I
nearly cried when I saw aj:commentCount ;-)
- James
John Panzer wrote:
We just deployed support for [EMAIL PROTECTED]previous et al. for AOL
Journals. If anyone has a client that makes use of these links, please
Yeah, I know. Just to put it in perspective, that field is much older
than Atom 1.0. :)
Looking forward to linking together our entry and subsidiary comment
threads using threading extensions (and moving the comment count to the
comment feed)...
James M Snell wrote:
Just ran it through my
We added support for next/prev/previous links in version 0.3.0 of Snarfer
[1]. We don't use the reconstruction algorithm suggested in the Feed History
draft, but your example feed seems to work ok for an initial retrieval.
There may be problems with subsequent updates, though, depending on
27 matches
Mail list logo
