4 ms·

> PubSubHubbub evolved and is now able to work with any kind of data (not just RSS or Atom), opening the door to a JSON based syndication format. It is not mad

by lwf 13y ago

> PubSubHubbub evolved and is now able to work with any kind of data (not just RSS or Atom), opening the door to a JSON based syndication format. It is not made clear why this is desirable. The author makes no case for why a JSON-based system would be any better than the current XML system. Perhaps the implied "eww XML", but XML is the standard.

ancarda 13y ago
JSON is smaller and easier to parse in JavaScript. Aside from that, there are no real advantages IMO.
- MatthewPhillips 13y ago
  Parsing RSS/Atom is a solved problem, don't do it yourself, use libraries.
  - finnw 13y ago
    Parsing JSON is also a solved problem. And JSON is also easier for humans to read than XML.
    - jarek 13y ago
      But is parsing an RSS-like format that uses JSON a solved problem?
      - dragonwriter 13y ago
        That's just parsing JSON and interpreting the data. Since parsing JSON and producing arbitrary object models is a solved problem, parsing an x-like format that uses JSON is also a solved problem for all x (developing the object model to use for it is an issue, perhaps, but you have to have that before you can have any serialization format, so that's not a distinguishing problem between different approaches.) Note that I am not, here, endorsing JSON over other alternatives; the same is obviously true of XML, HTML, YAML, or lots of other potential formats.
        jarek 13y ago
        Right, the only point I'm making is that ease of parsing JSON shouldn't count as a factor against RSS since RSS parsing is already more done than parsing any JSON-powered RSS alternative as the object model is already defined and implemented.
    - ancarda 13y ago
      Writing JSON is also easier by hand than XML, or at-least it is for me. Any time I'm planning a data structure I always use JSON since it's so well structured. XML is quite loose, unless I use plist theres no data types which is both an advantage and a disadvantage.
    - bct 13y ago
      > JSON is also easier for humans to read than XML. That's extremely debatable.
bct 13y ago
People are (slightly?) less likely to do the stupid "let's generate this structure by gluing strings together" thing that produced the need for liberal Atom and RSS parsers. (But yes, I agree that "turn this already-existing thing into JSON just because" is a stupid trend.)
- saurik 13y ago
  The thing that screwed RSS was not it being XML: I've seen the exact same issues happen any time someone has a text field in any file format. (Hell, I'm guilty of this.) They are more related to poor stewardship of a shared protocol than due to the usage of any particular transport encoding. The first issue is that you have a field, and that field is rendered in a text box, and is defined to be text; at some point you go "man, I wish I could add a hyperlink to my text", and so you now want to put some HTML in there. However, the field is just text, so what do you do? Let's say this was JSON, and this text is a string; do you put HTML in the string? This is somewhat equivalent to putting escaped HTML into the text node of the XML document. Alternatively, you could replace the string with an object (vaguely equivalent to putting HTML elements in the RSS). The result of some people choosing the first option (which seems more reasonable at first glance than the second option, as it provides a better experience for existing readers and better fits the existing protocol) is having to look at a string and guess whether it should be parsed as HTML or not. The second problem is that as people make changes in the second direction, if they are not carefully organized and centralized in a specification, you end up with haphazard and incompatible changes: someone decides to add a "type" field with a mime type, someone else adds a different element. Having a ton of people generate the format, and having the thing parsed by some liberal canonical language, leads to too much flexibility in fields like dates: someone puts a weird date format into their date field, and it is parsed correctly, and then tons of other people do it, and you're screwed. This also isn't helped by going with JSON: the field is just more likely to end up being "anything that a JavaScript Date object is willing to convert from a string to a date", which assuredly supports irritating corner cases that are not supported by the Date parsers from other random languages. With RSS, it was really "the peoples' protocol", with the specifications only encoding random changes that had become popular over time. What we were left with was a total mess: I can't find it now, but someone once wrote a proof that you couldn't actually parse RSS due to conflicting standards.
julien 13y ago
Many people have argued that RSS is too complex compared to JSON... and to be fair it's clear now that every new API from every service is JSON based. At this point, XML is clearly on the way out for web people!
- bct 13y ago
  That's the same kind of attitude that caused the decade of "XML for everything, and damn the technical requirements".
  - julien 13y ago
    Agreed, and we (superfeedr) have been strong advocates of XML for some problems. We are also tired of hearing: give us JSON or we won't care about RSS.

by lwf 13y ago

ancarda 13y ago

JSON is smaller and easier to parse in JavaScript. Aside from that, there are no real advantages IMO.

MatthewPhillips 13y ago
Parsing RSS/Atom is a solved problem, don't do it yourself, use libraries.
- finnw 13y ago
  Parsing JSON is also a solved problem. And JSON is also easier for humans to read than XML.
  - jarek 13y ago
    But is parsing an RSS-like format that uses JSON a solved problem?
    - dragonwriter 13y ago
      That's just parsing JSON and interpreting the data. Since parsing JSON and producing arbitrary object models is a solved problem, parsing an x-like format that uses JSON is also a solved problem for all x (developing the object model to use for it is an issue, perhaps, but you have to have that before you can have any serialization format, so that's not a distinguishing problem between different approaches.) Note that I am not, here, endorsing JSON over other alternatives; the same is obviously true of XML, HTML, YAML, or lots of other potential formats.
      - jarek 13y ago
        Right, the only point I'm making is that ease of parsing JSON shouldn't count as a factor against RSS since RSS parsing is already more done than parsing any JSON-powered RSS alternative as the object model is already defined and implemented.
  - ancarda 13y ago
    Writing JSON is also easier by hand than XML, or at-least it is for me. Any time I'm planning a data structure I always use JSON since it's so well structured. XML is quite loose, unless I use plist theres no data types which is both an advantage and a disadvantage.
  - bct 13y ago
    > JSON is also easier for humans to read than XML. That's extremely debatable.

bct 13y ago

People are (slightly?) less likely to do the stupid "let's generate this structure by gluing strings together" thing that produced the need for liberal Atom and RSS parsers. (But yes, I agree that "turn this already-existing thing into JSON just because" is a stupid trend.)

saurik 13y ago
The thing that screwed RSS was not it being XML: I've seen the exact same issues happen any time someone has a text field in any file format. (Hell, I'm guilty of this.) They are more related to poor stewardship of a shared protocol than due to the usage of any particular transport encoding. The first issue is that you have a field, and that field is rendered in a text box, and is defined to be text; at some point you go "man, I wish I could add a hyperlink to my text", and so you now want to put some HTML in there. However, the field is just text, so what do you do? Let's say this was JSON, and this text is a string; do you put HTML in the string? This is somewhat equivalent to putting escaped HTML into the text node of the XML document. Alternatively, you could replace the string with an object (vaguely equivalent to putting HTML elements in the RSS). The result of some people choosing the first option (which seems more reasonable at first glance than the second option, as it provides a better experience for existing readers and better fits the existing protocol) is having to look at a string and guess whether it should be parsed as HTML or not. The second problem is that as people make changes in the second direction, if they are not carefully organized and centralized in a specification, you end up with haphazard and incompatible changes: someone decides to add a "type" field with a mime type, someone else adds a different element. Having a ton of people generate the format, and having the thing parsed by some liberal canonical language, leads to too much flexibility in fields like dates: someone puts a weird date format into their date field, and it is parsed correctly, and then tons of other people do it, and you're screwed. This also isn't helped by going with JSON: the field is just more likely to end up being "anything that a JavaScript Date object is willing to convert from a string to a date", which assuredly supports irritating corner cases that are not supported by the Date parsers from other random languages. With RSS, it was really "the peoples' protocol", with the specifications only encoding random changes that had become popular over time. What we were left with was a total mess: I can't find it now, but someone once wrote a proof that you couldn't actually parse RSS due to conflicting standards.

julien 13y ago

Many people have argued that RSS is too complex compared to JSON... and to be fair it's clear now that every new API from every service is JSON based. At this point, XML is clearly on the way out for web people!

bct 13y ago
That's the same kind of attitude that caused the decade of "XML for everything, and damn the technical requirements".
- julien 13y ago
  Agreed, and we (superfeedr) have been strong advocates of XML for some problems. We are also tired of hearing: give us JSON or we won't care about RSS.