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 the name of a local file it can store state in (if
you run it again in the future, it won't fetch what it's already
seen) and url is the feed.
One thing I did notice -- you're using URLs like this for your archives:
http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2&count=10
Are they really permanent? If they're relative to the current state
of the feed (i.e., the above URI means "give me the ten latest
entries"), you can get into some inconsistent states; e.g., if
somebody adds/deletes an entry between when the client fetches the
different archives. Also, if a client doesn't visit for a long time,
it will see
http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2&count=10
and assume it already has all of the entries in it, because it's
fetched that URI before.
On 2006/04/26, at 6:36 PM, 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 let me know, I'd love to see if there are any
interoperability problems.
Example Atom feed: http://journals.aol.com/panzerjohn/
abstractioneer/atom.xml
Thanks,
--
John Panzer
System Architect
http://abstractioneer.org
--
Mark Nottingham http://www.mnot.net/
