Sparkle has appcast as a sort of defacto standard and Adobe have developed their own variation on that: http://learn.adobe.com/wiki/display/ADCdocs/Adobe+Appcasting+Namespace+Extension And DOAP is another interesting take on this same idea, designed around open source projects.

I assume (but haven’t found) that Android has some sort of application feed, given the number of Android ‘rate this app’ sites out there alongside the official market website. Or maybe there are lots of people scraping information from the official website?

Imagine a world where the unix packaging and collection sites (such as http://freshports.org) could tie into upstream application feeds to link to release notes, release dates, and much more. CVE security notices could be added to each release (posthumously of course) and many tools could consume this information, aggregate it in different ways and provide useful tools for the end-user. Imagine if developers could implement this uniformly across Windows, OSX, Android, Unix and whatever else.

Sparkle’s appcast is the closest we have to this overall goal. But given that your link to Sparkle2 is dead, it looks like Sparkle might be aiming at smaller OSX specific ideals these days. I raised an issue in their bug reporter to see if there is a discussion at Sparkle about the bigger picture: https://answers.launchpad.net/sparkle/+question/168644

Right now, I’m not sure what to do about all this. My needs are small, and I hope that someone like the Sparkle devs who already have a large mindshare would be interested in picking up this baton. You or I might write a schema that was brilliant, but if nobody used it…

Unless I get some response from Sparkle I will probably reinvent this wheel (or build on DOAP or Sparkle) for my own application needs. Then publish a blog entry somewhere, consigned to the history of sort-of-good ideas that never took hold.

I don’t agree with you that unification is not desirable these days. Yes, there are a multitude of workflows and upgrade processes; but the application release data format is pretty much the same throughout.

We’re now slowing moving into a world that provides isolated solutions for the software update problem anyways (see Mac App Store, see all the mobile App Stores, see the talked about Windows App Store), and these setups today provide much more than just a stream of updates to install.

Also, I’m not sure if my original idea of the “unification” of the whole process is the right way to do it today – after all each platform has its own design guidelines, workflows, UIs, and so on, and people simply expect that something like this would be implemented deeply inside and in congruence with the rest of the system.

So, to make the whole thing useful outside the developer world, we clearly have to define some new use cases about which Joe User actually cares.

Why are we trying to fit this inside an RSS data structure anyway?

Did you make any progress in the last 4 years or find anyone else who did? The Sparkle2 link is also dead.

http://sparkle.andymatuschak.org/wiki/Sparkle2

If they set their format in stone, one could certainly look into it more in detail and provide alternative implementations for it.