Hi, > > At least, that's our working hypothesis. As for partial packages, the > > point is to consume bandwidth only for the bits you actually need. There's > > little point in slurping down 1.6GB of Solaris every two weeks if only > > 300MB has actually changed. > > Hear hear! >
As in SVR4 patches. You deliver just what is needed. > > > > The downside with zip in particular is that the table of contents is at > > > > the end of the file, which means that you can't do anything with it > > > > until you've finished downloading it. > > > > > > Yes, but you wouldn't want to do a software transaction until you actually > > > had all the data to hand. (If you're pulling this from a repository, > > > metadata > > > operations could be done independently.) > > > > Right. One thing I didn't understand about zip archives was that each file > > was compressed individually, making it possible to unpack an archive > > knowing only the boundaries between the files. If the server is capable of > > serving up that information while the client is downloading the rest of the > > data, then we can achieve a kind of streaming. > > Per-file compression also allows you to construct the archive > on-the-fly in the repository server. The ToC at the end of a zip > archive was one reason why Conary implemented its own archive format. > Why not to use something like pax if all objects are already compressed? Best regards, Milan
