Okay, that's quite simple then: though this document does happen to be well formed, it's not anything like valid rss 1.0 which is the particular flavour it appears to be aiming at. Checking against a validator, seems the feed's idea of what a <channel/> element should be and the spec's idea are not the same, need an rdf:about attribute and a <items/> child element.
Wouldn't atom be easier than this soup?
Rar
Live Feeds (alternative notification)
Moderator: AniDB
Clearly not the best supported format if you don't read the spec or ensure that the xml is well formed... {\endassholemode}
I'd suggest you just use something for feeds of CPAN, but imagine all the other perl programmers are much the same in thinking that specs are for chickens and xml tastes better when you print your own tags. {\reallyendassholemode}
Rar
I'd suggest you just use something for feeds of CPAN, but imagine all the other perl programmers are much the same in thinking that specs are for chickens and xml tastes better when you print your own tags. {\reallyendassholemode}
Rar
-
hardjowikr
- Posts: 16
- Joined: Mon Jan 08, 2007 9:55 pm
If you add feed: in front of the URL like feed:http://anidb.info/perl-bin/animedbrdf.pl?id=xxxx most browsers can add this feed without the need of right-click -> copy addr... or right-click -> add feed
I did a quick rewrite of the feed code to atom last night as a test. (and didn't actually run it, thanks for fixing all the syntax errors exp ;_; )
To reply to some of exp's questions from CVS, I'd altered the key generation because I thought this 'd be a disruptive change, and perhaps something we want to test seperately before (if) we replace the rss version. Either way is fine though, there's not actually much code to test involved, or many users yet.
On the serialisation prettiness, I've not actually seen what it looks like. However, XML::Atom is a paper thin wrapper that 'd already considered junking (as it doesn't actually do anything useful like ensure validity), so can chuck that and code straight to the xml library, which will take out anything stupid the module is doing with namespaces etc. Remember you can Content-Encoding-er the document too for transport savings (when it's not just a 304 reply).
On refresh hints, in potentia the exact same three elements you were using before
(<updatePeriod/><updateFrequency/><updateBase/> in the http://purl.org/rss/1.0/modules/syndication/ namespace) could be incorporated again, as that's how XML teh is. It's a question of whether clients are coded to honour (or even notice) them.
Rar
To reply to some of exp's questions from CVS, I'd altered the key generation because I thought this 'd be a disruptive change, and perhaps something we want to test seperately before (if) we replace the rss version. Either way is fine though, there's not actually much code to test involved, or many users yet.
On the serialisation prettiness, I've not actually seen what it looks like. However, XML::Atom is a paper thin wrapper that 'd already considered junking (as it doesn't actually do anything useful like ensure validity), so can chuck that and code straight to the xml library, which will take out anything stupid the module is doing with namespaces etc. Remember you can Content-Encoding-er the document too for transport savings (when it's not just a 304 reply).
On refresh hints, in potentia the exact same three elements you were using before
(<updatePeriod/><updateFrequency/><updateBase/> in the http://purl.org/rss/1.0/modules/syndication/ namespace) could be incorporated again, as that's how XML teh is. It's a question of whether clients are coded to honour (or even notice) them.
Rar
I noticed @ not run x_X
Please note that the adm/anidbrdf.pl file would also need to be ported to make use of the feed stuff. That file generates the latest additions feed. (cron job)
That one is easier to test too @ development server, just run it manually.
It would still be interesting to know if atom is really all that well supported by feed readers. It's a pretty new format, isn't it?
And also which of them would support rss style update tags in an atom feed.
So why not use RSS/RDF? Should be easy to fix the syntax problems the old feeds have, or not?
I mean, what do we gain by using atom as format?
BYe!
EXP
Please note that the adm/anidbrdf.pl file would also need to be ported to make use of the feed stuff. That file generates the latest additions feed. (cron job)
That one is easier to test too @ development server, just run it manually.
It would still be interesting to know if atom is really all that well supported by feed readers. It's a pretty new format, isn't it?
And also which of them would support rss style update tags in an atom feed.
So why not use RSS/RDF? Should be easy to fix the syntax problems the old feeds have, or not?
I mean, what do we gain by using atom as format?
BYe!
EXP
Yeah, I'd seen there was one more file, thought I'd start small, might have been more sensible to go for that one first than the per-user code though.
On the support front, I think everything that matters understands atom. We're happy discouraging IE on the browser front, so it's not like we need to worry about supporting dusty feed readers.
For the update tags, note they are in a completely different namespace from rss 1.0 - do you know how many things that call themselves 'rss readers' *currently* understand them? And how relevant is it? What we're using at the moment hints at an hourly check, the default update in most clients won't be faster than that. ...and can't we use HTTP for this stuff? Just tell the client to cache the damn thing for an hour.
As for actual benefits, there's a bunch of xml-perspective reasons to prefer atom that no one but me 'll care about, but for our current it's pretty much trading like-for-like. Should we want to provide something a bit flasher in the future than plain text content blobs though, that's actually an option without inevitably breaking current use. Even if treated just as a mop up job of the rss trainwreck there's the benefit of the name clarity: we can provide 'atom' feeds, and any problems are either us or the reader not matching that one spec; but if we provide 'rss' feeds then there's not even a baseline compatibility we can aim at because it means a whole bunch of completely different things.
Rar
On the support front, I think everything that matters understands atom. We're happy discouraging IE on the browser front, so it's not like we need to worry about supporting dusty feed readers.
For the update tags, note they are in a completely different namespace from rss 1.0 - do you know how many things that call themselves 'rss readers' *currently* understand them? And how relevant is it? What we're using at the moment hints at an hourly check, the default update in most clients won't be faster than that. ...and can't we use HTTP for this stuff? Just tell the client to cache the damn thing for an hour.
As for actual benefits, there's a bunch of xml-perspective reasons to prefer atom that no one but me 'll care about, but for our current it's pretty much trading like-for-like. Should we want to provide something a bit flasher in the future than plain text content blobs though, that's actually an option without inevitably breaking current use. Even if treated just as a mop up job of the rss trainwreck there's the benefit of the name clarity: we can provide 'atom' feeds, and any problems are either us or the reader not matching that one spec; but if we provide 'rss' feeds then there's not even a baseline compatibility we can aim at because it means a whole bunch of completely different things.
Rar