Taking appcasts to the next level

Appcasts are RSS feeds which make use of the <enclosure> tag which links to a binary file (usually a software package) somewhere on the internet. Sparkle, a library drop-in for Objective-C/Cocoa Mac OS X development, implements and expands this format to use it as transport description for application updates. With this, Sparkle makes it possible to automatically trigger application updates in a well-defined, consistent way. It downloads, unpacks and replaces the original binary and afterwards restarts the updated application.

I’m sure most of the Mac users out there have already seen it; many popular programs support self-updates through appcasts and Sparkle (hell, even guitone has an appcast after I managed to hack Sparkle support into this Qt project), it makes the whole process of updating non-Apple applications on a Mac so much easier and fun. With the advent of AppFresh, which aggregates all the registered appcasts from all locally installed applications and then updates them all-at-once, appcasts become an interesting idea for software distribution at a larger scale.

Now, GNU/Linux users will probably laugh at me when I tell them from this “superior” technique, because appcasting is a well-known technique in the free software world: A software update (if not automatically triggered) is usually done in the background by modern Linux distributions through yum or apt, with full support for version and dependency checking, mirror localisation and much more. Interestingly, these software distribution systems never made the jump to other operating systems – and yes, I know of MacPorts and Fink, but both are different story, because they distribute mostly GNU software.

There is one thing which distinguishs appcasts from GNU/Linux distribution systems, and this is rooted in the way software is developed on both platforms. GNU/Linux software projects usually just provide the sources, which are then build for the specific distribution and platform by so-called packagers. These packagers have not necessarily anything to do with the actual project. Because there are so many distros out there, a software gets quite a lot repackaged, even if some of these packages basically serve the same platform and architecture.

Mac OS X software (and Windows software as well) is usually distributed directly in binary form, ready to use for the defined platform. The “packager” role is here an internal role of the software creator and the distribution – if not done through the software creators home page – usually happens via big download sites like macupdate.com, cnet.com and others. All these websites are isolated “applications”, meaning that they use different internal data formats, are usually closed and don’t work together in most cases.

So, the new hype, not only in content creation branch, is syndication. And that is exactly what appcasts are about: Based on RSS 2.0 they provide a general format to describe software updates. Platforms like iusethis.com use the feed and provide additional services, f.e. a global “usage counter” for a particular software package. However the problem with the current appcast format pushed by Sparkle is, that it is itself an isolated application, because it can only provide “some package with some version to download somewhere” and includes no information about other platforms, architectures or download locations. This may be ok as long as you either have different appcasts for all these different platforms or only target one platform (in case of Sparkle Mac OS X).

But what if you create an application which should run on all major platforms? You certainly want to provide your users the same look’n’feel and features on all these platforms, and this is where my proposal drops in. My aim is to create a cross-platform format for software updates which is suitable to distribute update information for any platform through one single stream of information. Based on this format people could create those kind of library drop ins like Sparkle not only for Mac OS X, but for multi platform toolkits like Qt, wxWidgets, even for .NET. Software developers would then simply add those in their projects, provide the syndicated format on a webserver, and are done.

So again, what are the advantages here?

• Based on the specification, an application update would “feel” the same on every platform, maybe with slightly differences between the different toolkit implementations
• The syndicated format, which extends RSS 2.0, could serve as common content feed in any feedreader and, at the same time, transport the needed update information for the application drop ins
• The feeds are decentralized published; the power is taken back to the software creator as he determines how he publishes his software
• Other services similar to iusethis.com could arise which would provide social functionality around software updates, caching, mirroring and more

Of course the whole proposal would probably make most sense for Windows and Mac OS X software creators, since, as I already mentioned, distribution in the GNU/Linux world happens quite differently (and these people usually don’t like to build binaries themselves, they let packagers from the different distros do this work). But why should efforts like AutoPackage not be supported, if they’re interested? And I think commercial Linux software distributors would be interested in that as well, just because it would strengthen their relationship with their customers quite a lot.

What follows is a quick effort how such a format could look like. It currently doesn’t contain the RSS part, because I think you all know how this would look alike, I plan to put one <software> node into each <item> which would then stand for an invididual software release. Below the software node, the following tree would be expanded (which should be mostly self-explanatory):

  2.2.3
  
    
      
        source
        application/x-compressed
        2928399933
        012346789ABCDEF012346789ABCDEF
      
      manual
      
        
        
      
    
    
      
        binary
        application/octet-stream
        2928399933
        012346789ABCDEF012346789ABCDEF
      
      app-replace
      
        
        
      
    
    
      
        binary
        application/octet-stream
        2928399933
        012346789ABCDEF012346789ABCDEF
      
      installer
      
        
        
      
    
  

Of course some concepts are stolen from Sparkle (f.e. hashs to check the data integrity of downloaded files), and one could put a lot more stuff in this. I once thought about adding support for “upgrade paths” into it, f.e. if a user skips a couple of versions, he should be notified if his current installation can be updated (using binary patches) or has to be upgraded (which requires a full installation), but I think bandwidth is cheap nowadays and it would make a first shot of this format and its implementation far too complex.

So, this is it, what do you think? I’d love to hear your feedback! I’m in contact with the developers of AppFresh and they signalled interest as well. Stay tuned for more news in the future!