Auto-update of native application bundles

Richard Bair richard.bair at
Fri Jun 15 13:31:41 PDT 2012


On my blog[1] I posted an article linking to Igor's blog about application deployment. I went on to describe scenarios where native app bundles do not require auto-update (primarily, when dealing with IT department's distributing MSI files or when using an app store), and conversely those that do require auto-update (just about everything else). I mentioned that I've been talking with Dan Zwolenski (aka Zonski) about Sparkle and auto-update requirements and he's been building a prototype.

There are basically two ways we can take this. The first is that we can try to find some native auto-update system on each of the desktop operating systems, and then build a think Java API that sits on top of these. This approach would allow us to leverage existing code and get some robust auto-update in place much quicker. On mac for instance we would just use Sparkle and it would be rock solid from day one.

I have concerns about this approach. First, the mechanism by which you communicate with the application that it is time to update is likely going to be different for different native auto-update frameworks. Sparkle for example uses "app casting" -- an RSS feed with a URL to the new version. Google's auto-update frameworks probably use some other mechanism. I think it is unacceptable to ask developers to use multiple different deployment mechanisms for telling the app that it is time to update. So that would then suggest we have to have some custom code + Java API + native auto-update frameworks -- now things are getting complicated. Plus, different frameworks have different feature sets, so we either have to use the intersection of APIs supported by all, or we have to modify frameworks with features that are missing.

I don't think it should really be that complicated. I think that essentially doing an auto-update mechanism in nearly all Java (with a minor bit of native code) would reduce the numbers of bugs we have to deal with over all, and would also ensure the same API across all of the desktop operating systems (or embedded systems that don't force the use of an app store). Sparkle is very versatile and yet essentially maintained by one guy, so I think it should be feasible that we could support a similar feature set in Java.

I've asked Dan if he wanted to spearhead this work and he's been enthusiastic about doing so. With that introduction, Dan, the rest is your's :-).

I'm hoping we can put the auto-update mechanism into the lombard repositories (what we're calling 3.0) as soon as they open. In the meantime I know he has a prototype for Windows.



More information about the openjfx-dev mailing list