Request: JSON Feed Format #905

Closed
bdkjones opened this Issue Oct 29, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@bdkjones

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.

Since NSJSONSerialization exists and is dead-simple to use, could Sparkle adopt JSON for the feed? I mean, just look at the difference:

{"updates": [
    {
     "title": "Version 3.0",
     "pubDate": "Saturday, 29 October 2016 20:00:00 -0700",
     "releaseNotesURL": "https://somedomain.com/notes.html",
     "dsaSignature": "MCwCFDl/hM1o3DeBQw6RlPP8XKlLIGzwAhQ+lqH3I6pCOXmb9naBKm/siMTnTg==",
     "url": "https://somedomain.com/app.zip",
     "version": "3.0.1",
     "shortVersionString": 25434,
     "minimumSystemVersion": 10.11
    }
]}

It's simple, readable...doesn't make your eyes bleed. What's not to love?

@zorgiepoo

This comment has been minimized.

Show comment
Hide comment
@zorgiepoo

zorgiepoo Oct 30, 2016

Member

This was brought up before in #427

Member

zorgiepoo commented Oct 30, 2016

This was brought up before in #427

@bdkjones

This comment has been minimized.

Show comment
Hide comment
@bdkjones

bdkjones Oct 30, 2016

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. NSJSONSerialization is a one-line method call to get an NSDictionary or NSArray of content. The hoops you have to jump through for XML parsing in Cocoa are ridiculous by comparison.

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.

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. NSJSONSerialization is a one-line method call to get an NSDictionary or NSArray of content. The hoops you have to jump through for XML parsing in Cocoa are ridiculous by comparison.

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.

@kornelski

This comment has been minimized.

Show comment
Hide comment
@kornelski

kornelski Oct 30, 2016

Member

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.
Sparkle will have to support both XML and JSON parsing for a long time though. People don't like pointless code churn, and we want everyone to keep updating. We're already asking devs to put effort into stronger security and to drop old macOSes. If we break too much, even for good reasons, we'll have a "Python 3". So for us it's supporting two parsers vs one, and sticking with one is always easier.

For developers serialisation would be easier indeed. However, for basic cases you can fudge XML feed generation with printf. If you edit manually there's no material difference — you just copy&paste and change text between "".

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 github2feed tool would be great).

Member

kornelski commented Oct 30, 2016

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.
Sparkle will have to support both XML and JSON parsing for a long time though. People don't like pointless code churn, and we want everyone to keep updating. We're already asking devs to put effort into stronger security and to drop old macOSes. If we break too much, even for good reasons, we'll have a "Python 3". So for us it's supporting two parsers vs one, and sticking with one is always easier.

For developers serialisation would be easier indeed. However, for basic cases you can fudge XML feed generation with printf. If you edit manually there's no material difference — you just copy&paste and change text between "".

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 github2feed tool would be great).

@jkbullard

This comment has been minimized.

Show comment
Hide comment
@jkbullard

jkbullard Nov 1, 2016

Contributor

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 NSJSONSerialization, including that it won't parse u-escaped invalid codepoints: ["\ud800"].

It also includes an example of JSON that crashes NSJSONSerialization!

Contributor

jkbullard commented Nov 1, 2016

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 NSJSONSerialization, including that it won't parse u-escaped invalid codepoints: ["\ud800"].

It also includes an example of JSON that crashes NSJSONSerialization!

@bdkjones

This comment has been minimized.

Show comment
Hide comment
@bdkjones

bdkjones Nov 21, 2016

Closing because it seems that there's no interest.

Closing because it seems that there's no interest.

@bdkjones bdkjones closed this Nov 21, 2016

@kornelski

This comment has been minimized.

Show comment
Hide comment
@kornelski

kornelski Jan 25, 2017

Member

Sparkle 1.16 comes with a tool to generate appcast automatically from files on disk. Hopefully with it there are fewer reasons to touch XML at all, so it won't bother you that much :)

Member

kornelski commented Jan 25, 2017

Sparkle 1.16 comes with a tool to generate appcast automatically from files on disk. Hopefully with it there are fewer reasons to touch XML at all, so it won't bother you that much :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment