Saving bandwidth, "the future of package management"

Question

I just imagine an "optimized" world, where each small change in a source code results only a small change in a binary "object" (which I imagine far smaller building elements than nowaday average packages -- but this thread is not about that), and only the changelog (not the whole object) will be streamed to the users. Every small piece of change gets transmitted only once. New users first download a "snapshot" of the object, then a connection will remain between the author of the object and the users, streaming the changelog (keeping in sync, auto-updating). 1 byte change in source results in 1 byte of stream transfer.
Last edited by nevempzub (2013-01-13 21:59:22)

Answer 1

I don't know much (aka anything) about binary diffs, and I may well have used the wrong tool.  But I just installed xdelta to see how small a binary diff might be based on the assumption that a small code change may have substantial alignment-type changes on the resulting binary.  I took a program I've been working on, compiled it, commented out two lines which implement a minor feature, then recompiled.
Both versions are about the same size at 23K.  The xdelta produced patch is 7K.
So, in one sense, that is a 3 fold savings.  But this would require the patches to be made upstream.  It would also require that one has a perfect always-on internet connection: what if you miss an update?  If you miss an update, the subsequent diffs will be against a version you don't have, so they will fail.  The only solution to this problem is that online repositories contain the history of all such diffs.
For my example, if this repository had to contain just 3 sequential diffs, this would eliminate the benefit.  Also for any user who had not updated since the 3 changes previous, they'd still be downloading something the size of the original package but then they'd have the additional cost of needing to apply each binary diff.
So, using only my single test case as an example, one might have to download three 7K diffs, then apply each one, or they could just download the new 23K binary itself and be done with it.  What if there were 4 changes since their last update?  five? etc ...
This would make it absolute hell to try to update any rapidly developing project - especially when it's pitched as grabbing every trivial change a developer makes rather than being based on versioned releases.  I make changes to my code daily.  Do you want a daily diff of probably more than that 7K example above, or would you prefer to just update every week or so with the newest 23K version of the program?
Last edited by Trilby (2013-01-14 12:39:35)