3 ms·

Yes. But please not RSS. At least newer initiatives like JSON Feed have maintainers who respond to requests for improvements. RSS feels like an abandoned stand

Yes. But please not RSS. At least newer initiatives like JSON Feed have maintainers who respond to requests for improvements. RSS feels like an abandoned standard. I tried to submit an improvement to the author directly to explicitly allow HTTPS URLs in light of upcoming iTunes changes to enforce HTTPS; they said by email that of course HTTPS resources are valid in their view, but they weren't prepared to actively update the spec to say as much. Until that's done some feed validators continue to mark HTTPS resources as invalid.

grzm 9y ago
I agree RSS is pretty crufty. (I've got a soft spot for Atom.) Do you have a list of validators that don't accept HTTPS resources as valid?
- modernerd 9y ago
  Feed Validator is one. (It returns “href must be a valid URL” for image resources that start https:// https:// because the RSS spec does not openly say that HTTPS image URLs are valid.) I tried and failed to change this, and was told that the RSS spec needed to change first: https://github.com/rubys/feedvalidator/issues/16 https://github.com/rubys/feedvalidator/issues/16 And I'm not the only one: https://github.com/rubys/feedvalidator/pull/30 https://github.com/rubys/feedvalidator/pull/30 I respect Sam's opinion in those threads because really the spec needs to change, but I've given up trying to change it. We ended up serving all feed URLs over HTTP as a result because customers using Feed Validator kept complaining that our product generated invalid feeds.
  - grzm 9y ago
    Thanks for the links. Do you happen to know if the validator accepts Atom with https resources? I'd think it should (if I'm understanding correctly), given that it uses IRIs, and IRIs support https as a protocol.
    - modernerd 9y ago
      Yes, it seems to validate Atom feeds with HTTPS image sources: http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Ftantek.com%2Fupdates.atom http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Ftant... Apple no longer supports Atom for podcasts, though, so unfortunately we couldn't use it as an alternative. (Podcast feeds must now be RSS 2.0: https://help.apple.com/itc/podcasts_connect/#/itc1723472cb https://help.apple.com/itc/podcasts_connect/#/itc1723472cb )
Bromskloss 9y ago
How does, in your opinion, JSON Feed compare to Atom?
- modernerd 9y ago
  In all honesty, “it's not XML” seems to be the main selling point. But that and the fact that it's on GitHub, which makes it more accessible to use and engage with for many developers, may be enough of a plus to embrace it. https://github.com/brentsimmons/JSONFeed https://github.com/brentsimmons/JSONFeed I also find the spec much easier to read: https://jsonfeed.org/version/1 https://jsonfeed.org/version/1 Beyond that they are similar and the mapping differences are described here: https://jsonfeed.org/mappingrssandatom https://jsonfeed.org/mappingrssandatom
pmlnr 9y ago
Does it matter, really? RSS, Atom, JSON, microformats, whatever; there are libraries that can parse any of these. What matters is the idea behind them, the technical implementation is secondary. Please don't revive the format wars.
- modernerd 9y ago
  I agree with the spirit of, “better to popularise independent syndication than fight over formats” except: > the technical implementation is secondary Until users get a bad experience that can't be solved easily because the spec was set in stone over a decade ago. Or until people want to extend and improve the spec to create new standards that prevent fractured and disparate extensions to it. Technical implementation is often secondary, but RSS already failed to achieve mainstream status once. That is not all down to the RSS spec, but recognising that RSS is a candidate for obsoletion and building on something active and progressive might give the idea of indie syndication a healthier second/third/fourth chance. A non-dead spec that's actively tended, marketed, and used for building great new platforms may garner more interest and prevent the “been there — tried that — it wasn't for me” that RSS seems to induce in non-techies.
  - pmlnr 9y ago
    RSS is good enough for what it was made for and most of the parser libraries and software parse both Atom and RSS (all 0.9, 1.0 and 2.0). Atom vs RSS caused enough trouble already ( https://indieweb.org/RSS_Atom_wars https://indieweb.org/RSS_Atom_wars ) and the solution is definitely not JSONFeed, just to break all previous feed reader implementation. Let us accept that any parser lib should be able to deal with RSS and Atom, and move on.
ttepasse 9y ago
> At least newer initiatives like JSON Feed have maintainers who respond to requests for improvements. Uhm. To my knowledge none of the issues in the JSONFeed Github repository ever caused a change in the JSONFeed spec. It's like talking into a black hole. A nice and friendly black hole, granted, but still a black hole. (Completely agree on the HTTPS issue.)
- modernerd 9y ago
  They have closed issues that resulted in small changes to the spec: https://github.com/brentsimmons/JSONFeed/issues/11 https://github.com/brentsimmons/JSONFeed/issues/11 I take your point that they're not addressed at the rate that issues come in, though.

grzm 9y ago

I agree RSS is pretty crufty. (I've got a soft spot for Atom.) Do you have a list of validators that don't accept HTTPS resources as valid?

modernerd 9y ago
Feed Validator is one. (It returns “href must be a valid URL” for image resources that start https:// https:// because the RSS spec does not openly say that HTTPS image URLs are valid.) I tried and failed to change this, and was told that the RSS spec needed to change first: https://github.com/rubys/feedvalidator/issues/16 https://github.com/rubys/feedvalidator/issues/16 And I'm not the only one: https://github.com/rubys/feedvalidator/pull/30 https://github.com/rubys/feedvalidator/pull/30 I respect Sam's opinion in those threads because really the spec needs to change, but I've given up trying to change it. We ended up serving all feed URLs over HTTP as a result because customers using Feed Validator kept complaining that our product generated invalid feeds.
- grzm 9y ago
  Thanks for the links. Do you happen to know if the validator accepts Atom with https resources? I'd think it should (if I'm understanding correctly), given that it uses IRIs, and IRIs support https as a protocol.
  - modernerd 9y ago
    Yes, it seems to validate Atom feeds with HTTPS image sources: http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Ftantek.com%2Fupdates.atom http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Ftant... Apple no longer supports Atom for podcasts, though, so unfortunately we couldn't use it as an alternative. (Podcast feeds must now be RSS 2.0: https://help.apple.com/itc/podcasts_connect/#/itc1723472cb https://help.apple.com/itc/podcasts_connect/#/itc1723472cb )

Bromskloss 9y ago

How does, in your opinion, JSON Feed compare to Atom?

modernerd 9y ago
In all honesty, “it's not XML” seems to be the main selling point. But that and the fact that it's on GitHub, which makes it more accessible to use and engage with for many developers, may be enough of a plus to embrace it. https://github.com/brentsimmons/JSONFeed https://github.com/brentsimmons/JSONFeed I also find the spec much easier to read: https://jsonfeed.org/version/1 https://jsonfeed.org/version/1 Beyond that they are similar and the mapping differences are described here: https://jsonfeed.org/mappingrssandatom https://jsonfeed.org/mappingrssandatom

pmlnr 9y ago

Does it matter, really? RSS, Atom, JSON, microformats, whatever; there are libraries that can parse any of these. What matters is the idea behind them, the technical implementation is secondary. Please don't revive the format wars.

modernerd 9y ago
I agree with the spirit of, “better to popularise independent syndication than fight over formats” except: > the technical implementation is secondary Until users get a bad experience that can't be solved easily because the spec was set in stone over a decade ago. Or until people want to extend and improve the spec to create new standards that prevent fractured and disparate extensions to it. Technical implementation is often secondary, but RSS already failed to achieve mainstream status once. That is not all down to the RSS spec, but recognising that RSS is a candidate for obsoletion and building on something active and progressive might give the idea of indie syndication a healthier second/third/fourth chance. A non-dead spec that's actively tended, marketed, and used for building great new platforms may garner more interest and prevent the “been there — tried that — it wasn't for me” that RSS seems to induce in non-techies.
- pmlnr 9y ago
  RSS is good enough for what it was made for and most of the parser libraries and software parse both Atom and RSS (all 0.9, 1.0 and 2.0). Atom vs RSS caused enough trouble already ( https://indieweb.org/RSS_Atom_wars https://indieweb.org/RSS_Atom_wars ) and the solution is definitely not JSONFeed, just to break all previous feed reader implementation. Let us accept that any parser lib should be able to deal with RSS and Atom, and move on.

ttepasse 9y ago

> At least newer initiatives like JSON Feed have maintainers who respond to requests for improvements. Uhm. To my knowledge none of the issues in the JSONFeed Github repository ever caused a change in the JSONFeed spec. It's like talking into a black hole. A nice and friendly black hole, granted, but still a black hole. (Completely agree on the HTTPS issue.)

modernerd 9y ago
They have closed issues that resulted in small changes to the spec: https://github.com/brentsimmons/JSONFeed/issues/11 https://github.com/brentsimmons/JSONFeed/issues/11 I take your point that they're not addressed at the rate that issues come in, though.