4 ms·

I think part of the issue with RSS is the real pain of dealing with XML. I'm mildly cheering for something like https://jsonfeed.org https://jsonfeed.org - whic

by kris-s 8y ago

I think part of the issue with RSS is the real pain of dealing with XML. I'm mildly cheering for something like https://jsonfeed.org https://jsonfeed.org - which would be a big step towards making a decentralized system more of a reality.

oliwarner 8y ago
Eh? It's not like teams of elves are tripping over hand-coding this stuff. And even if they were, JSON parsers tend to be way more strict than RSS readers (which are actuakly very liberal interpretations of XML). But again, nobody in their right mind is manually generating or templating this stuff. And if you are, there are a dozen RSS-gen libraries for every single language. Let one of those handle it for you. Doing this in JSON does not suddenly mean you don't need a convention (aka standard) for fields and types. It's data exchange. The reader needs to know what your data means. You still have pubdates, links, titles, descriptions and you still need to label them in a semi-strict way somehow. All in all, JSON will save you a few bytes but it would just be another standard on the pile, just with no libraries around to write the RSSJSON format. JSON doesn't fix XML.
- anoncake 8y ago
  > which are actuakly very liberal interpretations of XML This does sound painful, unlike parsing ordinary XML.
- spc476 8y ago
  Of the three formats I support, RSS, Atom, and JSON, the RSS feed is the smallest. RSS: 33,228 Atom: 43,433 JSON: 36,137
  - oliwarner 8y ago
    I'll be honest —and it'll make me sound like an arrogant dbag— but that doesn't pass my sniff test. "jsonfeed" is lighter than equivalent RSS for several small reasons. Can I see? (To be clear to anybody reading this out of context: I'm not claiming that JSON is best —far from it— just that I would expect it to be a few bytes lighter in transit.)
    - spc476 8y ago
      Sure. http://boston.conman.org/index.atom http://boston.conman.org/index.json http://boston.conman.org/bostondiaries.rss Each one contains the full text of the past 15 entries.
      - oliwarner 8y ago
        Thank you for sharing that. It took me a little while before I noticed it, but your JSON files have more data. Each item has a id, date_published and tags field which do not feature in the RSS. Together these account for around 250chars per item or 3750chars per 15 item feed. Cut out those fields and the JSON would be 850chars shorter. Also, you're preserving tab and newline characters around HTML. This affects JSON more because a newline is valid between RSS tags. In JSON a newline becomes two characters "\n", as a tab becomes "\t". Going "spaceless" on output would save you 1372chars from your JSON feed (and half as much from RSS/ATOM). I will confess, my sniff test didn't account for using quite as many HTML attributes as you do :) Escaping double-quotes costs you 334 in JSON. The overall difference is much slighter than I had expected.
tannhaeuser 8y ago
XML has worked just fine for RSS. The reason why RSS isn't as mainstream as it used to be around 2004 has nothing to do with XML, but is a consequence of Google capturing, than abandoning the audience, and of walled-garden social media taking off. Inventing a new JSON-based format in this niche is as helpful for adoption as matrix.org is for federated chat - it will only serve to fragment the space.
oftenwrong 8y ago
Working with XML as a simple data-interchange format is not any more difficult than working with JSON, and it is ubiquitous across all major programming language ecosystems. Beyond that, you can use powerful tools like namespacing, schemas, XSL, etc if you want them, and they are also ubiquitous across most major programming language ecosystems. They add complexity, but so do their JSON analogues. It seems that people often reinvent aspects of the XML ecosystem using JSON. For example, JSON Schema is like XML schema, OpenAPI is like WSDL, JSONPath is like XPath. That's not to say I don't support these efforts - I think it is great that people are developing powerful tools for JSON. However, I think there is a misconception that the XML ecosystem is less "à la carte" than the JSON ecosystem when it comes to these added complexities. You don't need to deal with them unless you need/want to, and then it is nice to have standardised, battle-tested implementations.
spc476 8y ago
So my blog [1] generates an RSS feed (early 2000s), an Atom feed (2009), a JSON feed (2017) and a Gopher [2] feed (2018). None of these formats were hard to add, and of all four formats, the JSON feed has the least use. Yes, the Gopher feed gets more use than JSON. If I go by "same client picks up feed at least one per day" then the results are: RSS: ~20 [3] Atom: ~25 [3] JSON: 1 gopher: 7 I don't think using JSON is any help towards a decentralized system of blogs. It's just another format to generate. [1] http://boston.conman.org/ http://boston.conman.org/ [2] My blog is also available via gopher, gopher://gopher.conman.org/ [3] Unique user agents---probably not the best metric, but for a quick scan, easy enough to check. Edit: formatting

by kris-s 8y ago

oliwarner 8y ago

Eh? It's not like teams of elves are tripping over hand-coding this stuff. And even if they were, JSON parsers tend to be way more strict than RSS readers (which are actuakly very liberal interpretations of XML). But again, nobody in their right mind is manually generating or templating this stuff. And if you are, there are a dozen RSS-gen libraries for every single language. Let one of those handle it for you. Doing this in JSON does not suddenly mean you don't need a convention (aka standard) for fields and types. It's data exchange. The reader needs to know what your data means. You still have pubdates, links, titles, descriptions and you still need to label them in a semi-strict way somehow. All in all, JSON will save you a few bytes but it would just be another standard on the pile, just with no libraries around to write the RSSJSON format. JSON doesn't fix XML.

anoncake 8y ago
> which are actuakly very liberal interpretations of XML This does sound painful, unlike parsing ordinary XML.
spc476 8y ago
Of the three formats I support, RSS, Atom, and JSON, the RSS feed is the smallest. RSS: 33,228 Atom: 43,433 JSON: 36,137
- oliwarner 8y ago
  I'll be honest —and it'll make me sound like an arrogant dbag— but that doesn't pass my sniff test. "jsonfeed" is lighter than equivalent RSS for several small reasons. Can I see? (To be clear to anybody reading this out of context: I'm not claiming that JSON is best —far from it— just that I would expect it to be a few bytes lighter in transit.)
  - spc476 8y ago
    Sure. http://boston.conman.org/index.atom http://boston.conman.org/index.json http://boston.conman.org/bostondiaries.rss Each one contains the full text of the past 15 entries.
    - oliwarner 8y ago
      Thank you for sharing that. It took me a little while before I noticed it, but your JSON files have more data. Each item has a id, date_published and tags field which do not feature in the RSS. Together these account for around 250chars per item or 3750chars per 15 item feed. Cut out those fields and the JSON would be 850chars shorter. Also, you're preserving tab and newline characters around HTML. This affects JSON more because a newline is valid between RSS tags. In JSON a newline becomes two characters "\n", as a tab becomes "\t". Going "spaceless" on output would save you 1372chars from your JSON feed (and half as much from RSS/ATOM). I will confess, my sniff test didn't account for using quite as many HTML attributes as you do :) Escaping double-quotes costs you 334 in JSON. The overall difference is much slighter than I had expected.

tannhaeuser 8y ago

XML has worked just fine for RSS. The reason why RSS isn't as mainstream as it used to be around 2004 has nothing to do with XML, but is a consequence of Google capturing, than abandoning the audience, and of walled-garden social media taking off. Inventing a new JSON-based format in this niche is as helpful for adoption as matrix.org is for federated chat - it will only serve to fragment the space.

oftenwrong 8y ago

Working with XML as a simple data-interchange format is not any more difficult than working with JSON, and it is ubiquitous across all major programming language ecosystems. Beyond that, you can use powerful tools like namespacing, schemas, XSL, etc if you want them, and they are also ubiquitous across most major programming language ecosystems. They add complexity, but so do their JSON analogues. It seems that people often reinvent aspects of the XML ecosystem using JSON. For example, JSON Schema is like XML schema, OpenAPI is like WSDL, JSONPath is like XPath. That's not to say I don't support these efforts - I think it is great that people are developing powerful tools for JSON. However, I think there is a misconception that the XML ecosystem is less "à la carte" than the JSON ecosystem when it comes to these added complexities. You don't need to deal with them unless you need/want to, and then it is nice to have standardised, battle-tested implementations.

spc476 8y ago

So my blog [1] generates an RSS feed (early 2000s), an Atom feed (2009), a JSON feed (2017) and a Gopher [2] feed (2018). None of these formats were hard to add, and of all four formats, the JSON feed has the least use. Yes, the Gopher feed gets more use than JSON. If I go by "same client picks up feed at least one per day" then the results are: RSS: ~20 [3] Atom: ~25 [3] JSON: 1 gopher: 7 I don't think using JSON is any help towards a decentralized system of blogs. It's just another format to generate. [1] http://boston.conman.org/ http://boston.conman.org/ [2] My blog is also available via gopher, gopher://gopher.conman.org/ [3] Unique user agents---probably not the best metric, but for a quick scan, easy enough to check. Edit: formatting