Auto-update of native application bundles

[Igor Nekrestyanov]

On 6/17/12 9:32 PM, Daniel Zwolenski wrote:
> I think I understand but please clarify any of the below if I got it 
> wrong.
>
> Would it be correct to say that the main difference is that in your 
> proposal you are working out the 'delta' update at compile/packaging 
> time, whereas in my solution the app works out the 'delta' at runtime 
> when an upgrade is requested. Assuming this is right, then:
>
> Because you are working deltas out at compile time you can bundle the 
> updates into a single image file and avoid having an app-profile. In 
> my solution I need everything extracted on the server with an 
> app-profile so the app can work out the diff in jar versions at 
> runtime. Your solution is definitely nicer on this front.
>
> On the other hand, because I work deltas out on the fly I don't need 
> 'delta' image files and any old version can always update to the 
> latest without downloading the full bundle even though no 'delta' file 
> exist. In your solution we have multiple deltas to maintain and the 
> more versions you have the more deltas you have to maintain (or not 
> use deltas, resulting in larger downloads). If a delta is not 
> available for a specific older version, then the app will have to 
> download the full update and install this.
Yes, process wise this is correct (there are other differences caused by 
above, e.g. single file, no way you may get components signed by 
different certs, etc.).

Example is correct too, some size overhead is expected but if we can get 
bundle size down with better compression methods/etc then difference 
will be not that big.
My expectation is that appropriate compression techniques can get size 
can be down to 25Mb for Ensemble. And once subsetting of JRE will be easier
(technically and legaly) it could probably get down to 15Mb or so.

Few clarifications on the example:

   1. In step 2 and 3 if all of older versions of app use same JRE then 
we can use "reduced" version of ful update that updates everything but 
runtime folder
       This can cut download size if it is an issue

   2. Full image for update may be the same as an app.
       E.g. we are currently installing same .dmg for JRE on Mac and you 
certainly can do silent installation with .msi

   3. The way to get full app image to compare against is not fixed.
       For example, you can save .zip of 1.0 version when you built 1.0, 
or install and zip image before you are ready to ship new version,
        or even manually provide list of files to include into update.

   4. Based on feedback i saw from Sparkle users and Oracle's use of AU 
for JRE keeping lots of delta's is not required.
       Interestingly delta's are often used not to improve user's time 
to update but to reduce server load.

Another point to consider is that use of single "update package" seem to 
be the way many other native update systems are implemented
(based on what i saw, clearly i am not familiar with all of them).

-igor