Multiple channel XML format

I just discovered that Adobe have written their own appcast syntax:

  http://learn.adobe.com/wiki/display/ADCdocs/Adobe+Appcasting+Namespace+Extension

Naturally, Adobe have done things their own way, however their extensions make a lot of sense. They have added license, category, links to source and docs. They all make sense.

Over at Apache we make quite a lot of use of DOAP:

   http://trac.usefulinc.com/doap
  http://projects.apache.org/indexes/releases.html

This is similar (XML documentation of releases), but goes quite a lot further. And it isn't wrapped inside RSS. I'd be interested in your opinion of how Sparkle's appcast syntax relates to these other similar efforts. Is it time to consolidate and better document this aspect of Sparkle?

Andy, I don't know if you find this useful (this conversation is better suited to a mailing list, but I couldn't find one)... I found another extension to the appcast schema:

  http://develop.participatoryculture.org/index.php/AppcastUpdate

They have added

    dtv:platform="windows"
    dtv:serial="20101206000"

Without a schema defining the enumerations for the attribute, "platform" isn't particularly useful. And it doesn't lend itself to more generic channels like "beta" or "professional"/"light". But it an interested extension of Sparkle none the less.

Should I stop now, or is this useful?

I never followed through on the demand for a more complex appcast spec because there wasn't much demand.

And I never wrote up a formal DTD for the appcasts because the only nodes / attributes are sparkle:releaseNotesLink, sparkle:version, sparkle:shortVersionString, sparkle:dsaSignature, and sparkle:minimumSystemVersion, which are all documented at https://github.com/andymatuschak/Sparkle/wiki/publishing-an-update.

I don't have the time to do the implementation support for this new format in Sparkle, but I'm certainly happy to chat about it or to take a look at pull requests.

OK, thanks Andy. I've just now discovered that you work at Apple, so I understand that your focus is just on Sparkle's OSX implementation. Fair enough.

The problems with extending your schema to other platforms is that some parts of your existing schema don't lend themselves to extension. In particular, there is a mixture of attributes inside <enclosure> and elements outside which are in the wrong place for a multi-platform approach, if there is to be one item with multiple enclosures (which is allowed by most RSS readers).

I would anticipate sparkle:platform is needed inside the enclosure, as well as things like sparkle:minimumSystemVersion. Fundamentally, you have conflated item and enclosure: which one represents the version released and which one the particular file to be downloaded? Why have you made some data attributes and other elements? What if the application has two components (eg. an application with additional optional modules)? How do we deal with applications with multiple 'types' such a Pro and Light version?

Perhaps your existing answer is always: create separate appcast feeds. But is that the best option, or just the current path of least resistance? I've already created my own schema and I'll document that and publish it somewhere soon. I'll make a note here when I do.

Finally, what happened to Sparkle 2.0? Was there a wiki page somewhere for planning?

Cheers
Ari

"…In particular, there is a mixture of attributes inside <enclosure> and elements outside…"

There are two elements outside the <enclosure> tag: <sparkle:releaseNotesLink> and <sparkle:minimumSystemVersion>. I think the former makes sense, since your release notes address a release, not an enclosure. The latter is misplaced, though, and would have to be converted into an attribute.

"What if the application has two components (eg. an application with additional optional modules)? How do we deal with applications with multiple 'types' such a Pro and Light version?

Perhaps your existing answer is always: create separate appcast feeds. But is that the best option, or just the current path of least resistance?"

Those are complex questions, and I've thought about them a great deal. I think the solution would be to "tag" releases ("paid-upgrade", "pro", etc), to specify some reasonable rules for "inheritance" of those tags along the poset, and to allow the updater's delegate to specify a filtering strategy for the releases in which it was interested.

The answer is presently "create separate appcast feeds" for the same reason that Sparkle 2 died: there wasn't enough interest in or need for the additional complexity to make a more powerful abstraction worth the development costs to me and the complexity costs to Sparkle's clients.