JSON Feed support?

[ksuther]

Would adding JSON Feed support to Sparkle be useful to anyone?

There's not any specific advantage for Sparkle itself, but it would make creating, managing, and reading appcasts a whole lot easier elsewhere. For example, tasks such as writing a script to automatically build an appcast, reading an appcast to ensure a download link is always downloading the latest version, and often be more straightforward with JSON than XML.

[dimitribouniol]

A specific use case could be to generate personalized appcasts much more easily via an API.

[jkbullard]

This has come up repeatedly. See #427 and #905.

Since #905, Sparkle has added an appcast-generating script.

[kornelski]

If JSON Feed catches on, we might follow.

So far I've been reluctant to add JSON support, because:

• It'd fragment the ecosystem. 3rd party tools consuming feeds would have to add JSON-sparkle-feed support as well.
• We can't drop RSS, so we'd have to maintain two formats.
• We now have the generate_appcast tool, so there's a way to avoid writing XML.
• There are some things that are easier in JSON, but it's not clearly superior. The syntax handling is also draconian, and inline HTML is harder to write.
• It doesn't solve any of our problems. If we were to change the feeds, addition of signatures (#971) seems like a higher priority, but because XML supports comments, it's easier to do them for XML than JSON.

In my experience with writing generate_appcast, dealing with XML wasn't too bad. Overall it was maybe 10% of the effort, and mainly because it tries to update a feed in-place, preserve unknown items and pretty-print.

Dealing with archives, selecting versions, generating deltas, and signatures took most of the work, and none of it is any easier in JSON. And if you just want to customize a feed a little, you can use any of the countless HTML templating tools.

[bdkjones]

An old thread, but I just googled this again to see if Sparkle had made progress on this front and discovered my issue (#905) from three years ago. I understand all the points above. But in my case, I'm now using my appcast file to transmit other information about updates that I use in some custom logic. To do that, I need to parse the file.

Here's how that would go with JSON:

1. Ask NSJSONSerialization to parse the file into an array of dictionaries, each representing an available update.
2. Use the data.

Here's how it goes with XML:

1. Set up NSXMLParser.
2. Set up a delegate for NSXMLParser.
3. Start parsing, receiving a delegate callback for every damn thing in the file.
4. Write a bunch of fragile, custom code to determine when the parser has hit information I'm interested in. Also keep track of which "update" we're talking about. Hell, we better just create an entire model class for this nonsense.
5. Waste a ton of time assembling all this stuff that's BASICALLY just an array of dictionaries, but NSXMLParser can't be told that so we have to do it all by hand.

In short: yes, JSON has limitations. But the tools to parse it are more modern, faster, and better than the tools to parse XML (at least in Foundation). Anyone who wants to do custom things with Sparkle's Appcast would be better off with JSON.

And yes, I realize I could just create a separate file. But then I have two files to maintain when I release an update. My goal is to have a single source of truth that's also modern and flexible; not tied to the 1990's.

[kornelski]

As for the original issue:

• it looks like JSON Feed didn't go anywhere.

• RSS isn't doing great either, so maybe it'd be OK to give up on compatibility.

• Still, Sparkle can't just drop XML, because that would be disruptive to existing users, so at best it has to support both, probably forever.

• We're now moving from Sparkle 1.x to 2.x, so fragmenting that further may not be a great idea. But maybe adding JSON to 2.x only could give users a reason to upgrade :)

Sadly Sparkle has bet on the wrong horse (that's from google trends with the date first Sparkle commit marked)

[kornelski]

As for the metadata - could Sparkle help you with that metadata?

It internally parses the feed into a dictionary, so maybe it could expose that, including some custom elements or attributes. You could even put JSON in an XML attribute if you want :)

[bdkjones]

It seems like JSON support wouldn’t be all that monumental of a task. Sparkle already uses a custom data class to hold information about updates. Populating that from a JSON file should be quite a bit easier than populating it from RSS/XML.

The third parties that implement Sparkle tracking (MacUpdate, etc.) would probably LOVE to use JSON instead because it’s also easier to parse in JavaScript and server-side languages.

Next, the XML stuff is done and tested. XML itself isn’t evolving, so there’s nothing Sparkle will need to do to keep supporting it. If new capabilities are added, those need only be added to the JSON side of things because (A) any new capabilities would be sugar—the core purpose of Sparkle is met with the existing XML feeds and (B) it would encourage users to move to JSON.

As for comments and html: are those frequently used in Appcasts? I would guess most folks handle release notes with an external link.