The idea of being able to randomly access portions of a new update RPM by doing byte range requests is interesting. It could in theory reduce the size of the delta file. However this only saves on mirror *disk space*. It does not reduce bandwidth consumption: the client still has to download this either in the delta file or by separate byte range requests. Looking at the size of the updates directory of the FC3/i386 (8GB+) I doubt that mirror maintainers would notice another GB or two. Anyhow, I would propose that any such delta RPM system allow more than one delta algorithm to be used, so if people come up with clever algorithms in future we can seamlessly incorporate it into the system without breaking anything already out there. Joe. On Thu, 17 Mar 2005 09:28:40 +0000, Nigel Metheringham <Nigel.Metheringham@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > While we are using 3rd party mirrors to distribute updates we will need > to have absolutely minimal requirements on the server to be smart - pure > dumb file serving over an existing protocol, maybe leveraging byte > ranges as the bleeding edge of requirements. >
