Auto-update of native application bundles

[Daniel Zwolenski]

Sounds good, and thanks for taking the time to clarify it all. 

I can see advantages to both approaches and could happily run with either. I think my POC is simpler for 'deltas' whereas yours is simpler for 'full' deploys. If bundles can be made small enough to make deltas generally not worth the hassle then I think your proposal is stronger. 

It would be good if we can get some input on this from the community and if Richard has any thoughts. 

One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version. Do you intend for the actual 'installation' to happen outside of the app using a native UI to show progress and success/error message or do you have some other trick in mind to update the jre while it is running?

Also the 'full' updates could always exclude the JRE if Oracle released JRE zip files that the updater could download from (based on a version specified in the update bundle). I don't suppose there's any chance of legals letting this happen?


On 18/06/2012, at 2:54 PM, Igor Nekrestyanov <igor.nekrestyanov at oracle.com> wrote:

> 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