Auto-update of native application bundles

[Daniel Zwolenski]

Thanks for your feedback Rick. Very good info and the way you would use AU
is very much in line with the way I would, with the exception that I rarely
have a payment requirement so it is good to think about.

Thanks for your earlier email too, I didn't want to reply all to the list
on that as I wasn't sure you wanted it to be in the public domain. It's
good to have your input in this forum.

Some further comments inline, but in general, I agree and would like to see
as much as possible, or all of your feedback, in the AU framework.


On Wed, Jul 25, 2012 at 2:31 AM, Rick Walker <thoughtslinger at gmail.com>wrote:

> Auto-Updater Feedback / Wishlist:
>
> We are keenly interested in the auto-updater and we greatly appreciate the
> efforts of all, especially Igor and Daniel. We anticipate posting app
> updates on a tight cycle – a week or two will be routine. So a clean,
> reliable auto-updater will make our users’ lives vastly simpler.
>

I am toying with the idea of creating an OpenSource project for AU outside
of JFX (i.e. not just a POC but a functional version with proper code). I
originally thought to wait until this could be included in JFX proper but
there are two possible advantages to doing an OSS one:

   1. It can be released sooner. AU is looking like it will be on the table
   for JFX 3.0 but that's not until late next year - if we start to use it we
   can also feedback to Igor on improvements/features
   2. An external-to-JFX version could use the runtime-delta approach as an
   alternative to the compile time delta approach, and then stay as an active
   alternative even after an official AU solution is included in the core JFX.

I'm tossing up whether this is a good idea (i.e. do we want two solutions
long term or is that just messy). Alternatively we could create a more
complete OpenSource version of the proposed compile-time updates (i.e. my
2nd POC). This then would be decommissioned once JFX proper has it
included. Does anyone have any thoughts on any of this?

One reason I wouldn't do this is just pure effort. My current client
doesn't want to use JFX (yet). As such, for me personally I could hold off
until 3.0 for this. So the reason to do it would be less for personal use
and more for the community - so how much do the community want this before
3.0?

Rick, I think you mentioned you'd worked on your own AU solution a while
back. If you, or anyone else, were interested in collaborating on this as
an external open source project I'd be very open to that idea.

Our app will require the user to log in and authenticate before launching
> the auto-updater. We would prefer to zip up our latest app jars and post to
> a predetermined location on our server. If the JRE does not change with an
> update, the updater should ignore it and retrieve only our app jars and/or
> updated T&C (see below).
>

The zipping of the jars probably won't work that well for the runtime-delta
approach (or at least I couldn't think of a way to make it work). The jars
need to be available unzipped to avoid downloading the whole thing. The way
you describe this usage it is very much inline with the compile time delta
solution that I last prototyped. In this case it's an all-or-nothing update
for you app (i.e. your jars and all 3rd party jars) but the JRE is an
optional extra download.

I'd be interested to know if you have a strong need/want for only updating
the jars that have changed within your app (e.g. yourapp.jar might have
changed but all the other included jars might not have) or would you not
care? This is really the heart of the runtime vs compile delta choice so
any feedback on this appreciated.

For me, I often have a GUI that's about 20MB+ once I include all the
dependent libraries (e.g. Spring, FOP, media, XML processing, HSQL for
offline storage, etc). My actual code might make up only a few MB of this.
If I am releasing weekly say (in an Agile approach) then this 20MB+ upload
and download can be an annoyance. It's not critical but it does seem
somewhat unnecessary. Typically I'll also be building and deploying to a
test environment on every check-in as well, so the delay because of slower
upload/download can also be annoying - especially if my test server is
remotely hosted and I'm working from home. Again we're in the annoyance
category here but I'd be curious if other people care or not about this.


Regarding jar signing, we expect to retrieve our app jars from our server.
> Even though we generally sign jars, we do not imagine performing a
> jar-signing check with each auto-update.



> We want to be able to tightly control auto-updates - we may ask users to
> pay for some updates. We are concerned that, by placing our jars at a url
> accessible to the auto-updater, we might also be inadvertently exposing
> them to anyone who might point a browser at the same url. Adding some level
> of indirection might help.
>

I think the only real way to ensure your users don't get hold of the app
jars is to use a client-side licence of some kind. i.e. the jars won't work
unless a licence key has been saved locally. A level of indirection on
downloads might stop the casual download but wouldn't stop someone willing
to go to a little effort. A client side licence shouldn't be too hard to
implement however. It could even be separate to the core AU framework: just
check on startup that the licence is available and if not, prompt for a
licence key. When you have an update, change the licence key rules in your
code, so when the updated app starts up, the licence check fails and the
user is notified.

Regarding updates to Terms and Conditions or EULA, it would be a great
> advantage to post an RTF (perhaps with a version number included in the
> file name) alongside our updated app jars so that the updater could
> determine whether the user ought to view and agree to the new T&C.



> I believe we include an RTF on the installer side (with NSIS or Inno) so
> it’s no extra work to also post it for the updater. We also routinely post
> updated T&C on our website, so I suppose a simple alternative might be for
> the auto-updater to simply point to that url.
>
> >From our perspective, it seems there are three components in play for the
> updater, each separately tracked for current version: the JRE, our app
> jars, and the T&C.
>
> Regarding user notification, we plan to use auto-updating to make sure that
> all users are using the same version of our app – just as if we deployed as
> an applet. User notification can therefore be bare bones – “a required
> update is now available’.  A "what's changed" document isn't required in
> our case.
>

This should all be fine to support.


> The download display can be modal – there is no need for the download to
> take place in the background.  An incremental progress indicator would be
> nicer than an indeterminate display.
>

Good to know - incremental progress indicator is definitely a requirement.
POC is a lazy implementation of this.

>
> Graceful recovery in the event of a failure state (stalled download, file
> i/o probs etc) is of course essential.
>

Agreed.


>
> Cheers to all,
> Rick
>