A more efficient up2date service using binary diffs

[M A Young]

On Wed, 9 Mar 2005, Jeff Spaleta wrote:

> Hard numbers on resource use.. its always better if you can produce them.
> Things are always about tradeoffs and client side benefits must be
> weighed against serverside resource constraints... and the only way to
> do that is to give relevant resource numbers for all resources of
> concern. Focusing on the resource the benefits.. is not going to win
> over people concerned about other aspects. I think everyone will
> stipulate to the fact that patches or deltas tend to save bandwidth if
> all you have to transfer over the wire are the patches or deltas..
> that's never been in dispute. The dispute is... is it worth it to
> implement. And you can't answer that question till you start looking
> at other resource constraints.

>From what I remember when I looked at this a while ago, if you use rsync
you need uncompressed rpms on the server and client (or dynamically
uncompress a file each time) to sync between, and you need to compress the
rsync communications or else the uncompressed differences may be bigger
than the rpms anyway.
If you generate a static delta file, such as with xdelta, you need
something like twice the size of the uncompressed rpm in disk space, and
probably once the size in memory to create the delta, and the
same disc space to regenerate the rpm on the client, but you can get big
savings on bandwidth, particularly when there have been minor changes to a
huge rpm, though at other times the delta is almost as big as the new rpm.

	Michael Young