Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Request: JSON Feed Format #905
XML is disgustingly awful. It's hard to write, it's difficult to read, it looks ugly, it's offensive and it killed a guy in 1972.
It's simple, readable...doesn't make your eyes bleed. What's not to love?
Thanks! I did a quick search for "json" before posting, but apparently that didn't include closed issues.
#427 was two years ago. Given the rise of Node and ECMAScript 2015+, the argument that JSON is a "passing fashion" really doesn't hold much water. Sure, data formats evolve and get better. But saying, "We won't support this standard that's clearly superior to the old one because someday there might be an even better standard" is not a good argument. Technology evolves. Keeping up with the times is part of being a developer.
JSON is easier for humans to read/write and easier/faster for machines to parse.
The "additional support" and "additional testing" don't really seem like valid arguments. You're just pulling the same key/value pairs. If Sparkle adds additional feed properties in the future, adding them to the JSON feed parser would be a few minutes of work, if that. I'd be happy to whip something up and contribute a PR if Sparkle is willing to incorporate it.
While I respect @pornel's opinion, I really think this idea should be revisited. JSON is objectively better all around.
XML isn't great, but for us it's a sunk cost. For end users it doesn't matter either way. There are nice things about JSON, but JSON isn't strictly superior to what we have (e.g. it's worse for inline release notes, lacks comments, and is not any less nitpicky about syntax errors than XML).
A new format would have to be so much better that it would pay off the high cost of switching. Cost is not only in writing a few ObjC calls to a JSON parser, but in fragmentation of documentation (our docs and on other sites), breaking compat with 3rd party tools/sites (mass-updater apps and version aggregator sites), and maintenance and testing past the initial PR.
I don't think JSON parsing being easy makes a difference here, because I expect most app developers generate the feeds, but don't parse them back.
For developers serialisation would be easier indeed. However, for basic cases you can fudge XML feed generation with
Writing the serialised syntax is not that hard compared to getting the data in the first place (especially things like DSA signatures). So for making developers' life easier and helping them generate appcasts, I think it'd be better to spend effort on tooling that completely automates it away, so that the developer doesn't even have to know what serialisation format is used.
JSON would make the tedious appcast-building task a bit nicer, but I'd rather focus on removing the task. For example we've been asked to support GitHub releases. It could completely eliminate feed maintenance (with that I have reservations on baking in support for a single commercial service, but something like
A recent presentation, Parsing JSON is a Minefield, further supports a decision to not support JSON as a feed format:
From the session description:
JSON is the de facto standard when it comes to (un)serialising and exchanging data in web and mobile programming. But how well do you really know JSON? We'll read the specifications and write test cases together. We'll test common JSON libraries against our test cases. I'll show that JSON is not the easy, idealised format as many do believe. Indeed, I did not find two libraries that exhibit the very same behaviour. Moreover, I found that edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because JSON libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all.
Section 4.4 of the presentation describes undocumented restrictions on
It also includes an example of JSON that crashes