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