5 ms·

There is no practical difference at all. RSS has more mindshare outside the google universe, but all reader read both, the formats can be mapped from the one to

by onli 9y ago

There is no practical difference at all. RSS has more mindshare outside the google universe, but all reader read both, the formats can be mapped from the one to the other, and all languages have libraries to create both. And also manually they are both equally easy to write. I for one opted to solely generate RSS wherever possible. Having two equally suited standards is a waste.

lifthrasiir 9y ago
But RSS's date & time format was practically messy (due to being not properly specified and enforced---take a look at [1]) and it had no way to specify that an article has been updated so it should not show up again to the timeline. When I had some dozens of feeds it had been quite annoying to mentally ignore updated articles. For the obvious reason (cough timely standardization cough) Atom is technically and often practically superior to the RSS family of formats (somehow not distinguished to each other). And after more than 10 years of usage, I'm pretty sure that every feed reader in the continued existence now has Atom support. [1] https://github.com/kurtmckee/feedparser/tree/develop/feedparser/datetimes https://github.com/kurtmckee/feedparser/tree/develop/feedpar...
- onli 9y ago
  No need to use the past tense here, I work on a project based on RSS feeds right now :) I'm not sure what I look at with the feedparser code. Looks like a bunch of format support libraries? https://cyber.harvard.edu/rss/rss.html https://cyber.harvard.edu/rss/rss.html says to use rfc822, and in practice for me that means just giving the date string to my chosen languages date object. You have a point with item updates, RSS was not really made for that. The blog engine I use has different options to handle that, I for one think just pushing a new entry with a new guid is the right solution; but then of course rss readers can't mark updates.
  - lifthrasiir 9y ago
    My point about date string is that, if people really honored the "specification" from the first place, why the `datetimes` directory has eight different files :-) I have personally seen lots of websites with Korean date & time format ("YYYY년 mm월 dd일 hh시 mm분 ss초", see `korean.py` there) and I'm not sure if they are now gone. (And yes I did have my own aggregation engine back then---it was at least born after feedparser though.)
    - onli 9y ago
      Ah, possible. I also use a normalization library (for both atom, jsonfeed and RSS), it might mask the worst of these occurrences.
    - pmoriarty 9y ago
      This "Korean date & time format" appears similar to ISO 8601, an international standard for dates and times: https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601
- qznc 9y ago
  Yes, but the self URL in atom feeds is tedious. It is the primary reason a static site generator requires a configuration to specify the domain where it will end up. RSS feeds can be copied to any domain and still pass validation.

by onli 9y ago

lifthrasiir 9y ago

But RSS's date & time format was practically messy (due to being not properly specified and enforced---take a look at [1]) and it had no way to specify that an article has been updated so it should not show up again to the timeline. When I had some dozens of feeds it had been quite annoying to mentally ignore updated articles. For the obvious reason (cough timely standardization cough) Atom is technically and often practically superior to the RSS family of formats (somehow not distinguished to each other). And after more than 10 years of usage, I'm pretty sure that every feed reader in the continued existence now has Atom support. [1] https://github.com/kurtmckee/feedparser/tree/develop/feedparser/datetimes https://github.com/kurtmckee/feedparser/tree/develop/feedpar...

onli 9y ago
No need to use the past tense here, I work on a project based on RSS feeds right now :) I'm not sure what I look at with the feedparser code. Looks like a bunch of format support libraries? https://cyber.harvard.edu/rss/rss.html https://cyber.harvard.edu/rss/rss.html says to use rfc822, and in practice for me that means just giving the date string to my chosen languages date object. You have a point with item updates, RSS was not really made for that. The blog engine I use has different options to handle that, I for one think just pushing a new entry with a new guid is the right solution; but then of course rss readers can't mark updates.
- lifthrasiir 9y ago
  My point about date string is that, if people really honored the "specification" from the first place, why the `datetimes` directory has eight different files :-) I have personally seen lots of websites with Korean date & time format ("YYYY년 mm월 dd일 hh시 mm분 ss초", see `korean.py` there) and I'm not sure if they are now gone. (And yes I did have my own aggregation engine back then---it was at least born after feedparser though.)
  - onli 9y ago
    Ah, possible. I also use a normalization library (for both atom, jsonfeed and RSS), it might mask the worst of these occurrences.
  - pmoriarty 9y ago
    This "Korean date & time format" appears similar to ISO 8601, an international standard for dates and times: https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601
qznc 9y ago
Yes, but the self URL in atom feeds is tedious. It is the primary reason a static site generator requires a configuration to specify the domain where it will end up. RSS feeds can be copied to any domain and still pass validation.