Many mornings, I wake up to a happy new ST2 beta. While that’s always a nice start to the day, it comes after a ~7MB download. I think you can do better.

Before I get started, note that I’m not concerned about downloading a few MB. I’m coming at this from the perspective of “how could I improve this if ST2 were my own project” rather than “darn that Jon for making me waste bandwidth!”.

With that out of the way, I used bsdiff to knock that down to just over 1MB. First, I use tar to make a backup of my old (version 2157) ST2 app:

$ cd /Applications; tar cvf /tmp/st2-old.tar "Sublime Text 2.app"

After installing this morning’s new version 2160, I repeated the process to make a copy of that release, then took a binary diff of those two tarballs:

$ cd /Applications; tar cvf /tmp/st2-new.tar "Sublime Text 2.app" $ cd /tmp; bsdiff st2-old.tar st2-new.tar stpatch-2157-2160.patch $ ls -la stpatch-2157-2160.patch 1085271

What I would propose would be maintaining a pristine copy of the ST2 archive on the user’s system. Alter the “Check for Updates…” function to download a manifest containing not only the most recent version number, but also a list of the most recent binary diff files (going back until the cumulative size of the diff files is greater than the size of the most recent full archive). If the user’s copy can be upgraded by downloading diffs and using them to update the local pristine copy, then do so. If not, or if the binary patching fails for some reason, then just download a new copy of the application - in other words, fall back to the current update procedure.

As a variant on that procedure, you could publish a set of binary patches from each of the last, say, 10 releases to the current version. Then users would only have to download a single diff file if they have a relatively recent version.

The advantages to users are that they can often upgrade to new ST2 releases with 1MB downloads instead of 7MB downloads. The advantage to you is that you can save an average of 6MB*(number of ST2 beta users who’ve upgraded recently) on your transfer bill.

Another alternative to this is Courgette/Omaha (the system employed by Google Chrome) - code.google.com/p/omaha/

Here they talk about the comparisons to bsdiff (chromium.org/developers/desi … -courgette)

Whoa! Thanks for the link. That’s pretty cool stuff!

I myself was thinking this the other day after re-reading Googles post about it. Seems like a good idea and I’ve long wondered why Jon doesn’t do this anyway.