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
