Recently I came across the hatom-sparkle project, that aims at extending Sparkle to support Microformats based appcasting. Even though, I am not sure if Microformats per definition are the best choice for enabling applications with auto-update functionality, it’s definitely worth having a look at it. The implementation is still not complete, mainly dealing with difficulties related to the HTML nature of Microformats as "Designed for humans first and machines second".
Right now, AppFresh supports Sparkle and iusethis.com based appcasts as well as Apples very own and closed, non-appcasting based Software Update. So for all applications, except those released by Apple, we first check for Sparkle appcasts and if none is available we check iusethis.com. Using those, there probably is no need to support Microformats based hatom-sparkle in AppFresh, but it would most certainly solve a lot of problems HTML parsing based solutions are facing. The lack of embedded semantics and the need of parsing "raw" HTML is exactly one of the reasons why AppFresh does still not support other updating plattforms, such as versiontracker.com, macupdate.com or apple.com/downloads, although it is the most requested feature since we published our first Development Preview. We think depending on layout based parsing of maybe frequently changing HTML sources you can’t control is not a stable solution, leading to broken functionality and the need of releasing updates on every change to a source. We therefore always wanted to support only a XML/RSS based format, that is..almost perfectly…provided by the appcasting concept. That is why using osx.iusethis.com as the only source for updating information is the best choice for AppFresh, that will get better and more up to date as the appcasting awareness of application developers and the sparkle user base itself rises. No need for buying tools, no need to use wordpress, or whatever…developers might just use iusethis.com to host and manage your appcasts.
The current problem with appcasting from our point of view, is the lack of an overall format defintion or specification. Well, its based on RSS, but there only are implementation specific extensions. Sparkle uses its extensions, iusethis.com uses other extensions and so on. The probably most advanced appcast definition, that is going beyond describing the use of the enclosure tag, is provided by the Sparkle documentation explaining its extensions. There is no easy and documented way for implementing cross-plattform (os x, windows, linux, whatever), multi-architecture (i386, ppc or universal), version-branch (2.0, 3.0, 4.0) or even license (free, commercial) based appcasts. Thomas Keller is writing about some of the issues mentioned and introduces a possible solution that is worth checking out and might be a first step towards a community discussion. It’s not complete either, but it shows the need and the interest in appcasting, that is going beyond Mac OS X. A public available definition and documentation would probably help a lot in increasing the awareness throughout the developer community and keep appcasting from being deadpooled like the codecasting project.
Based on a solid definition of appcasts, it would be more than useful to build a Microformat specification. This way developers and plattforms like iusethis.com could provide feeds and embedded semantics to provide centralized and decentralized updating information. Take appcasting to the next level.
