On Tue, 06 Nov 2001, toad wrote: > On Mon, Nov 05, 2001 at 07:31:26PM -0600, thelema wrote: > > On Tue, 06 Nov 2001, toad wrote: > > > > > On Tue, Nov 06, 2001 at 12:01:43AM +0000, toad wrote: <SNIP> > > > Also, if these are ISO images, you could insert the splitfile with a 2 kb > > > granularity? Of course, that means 600*500 = 300,000 files :) More > > > realistic > > > would be to insert the individual files as CHKs... since files will > > > normally > > > be packed on a CD-ROM, you can use a custom insert client that inserts > > > like > > > this: > > > CHK 1 per-CD header info, directory, etc > > > 2 FILE1.DEB > > > 3 short buffer to get to the next file > > > 4 FILE2.DEB > > > 5 another short buffer > > > 6 FILE3.DEB > > > <SNIP> > > > Etc. The individual DEB packages would match up with anywhere else they > > > have > > > been inserted (for example as part of apt-get-over-freenet), giving better > > > efficiency, and would also match up with later/earlier/other > > > distributions' > > > images. And it would all work with current clients (which allow variable > > > part > > > sizes), with non-redundant splitting. The buffers would all be less than > > > 2k, so > > > unlikely to go missing. One problem remains: if the packages are large, > > > they > > > may require redundant splitfile insertion themselves. So, can we have a > > > non-redundant splitfile containing segments which are redundant > > > splitfiles? Is > > > this a good idea? > > I don't agree that the small pieces are unlikely to go missing, but > > anyway... > > It's perfectly fine to have a non-redundant splitfile containing > > segments which are redundant splitfiles. It'd probably be better to > > insert all the .deb files and then have a recipie file that contains all > > the "short buffers" and enough other info to piece together the original > > ISO given all the .debs. > How does this differ from the short buffers thing? The missing data in the > short buffers is all NULLs, or can be changed to all NULLs with no damage. > We don't need to insert separate short buffers for each inter-file gap, we can > just use blocks of 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 null chars. > Incidentally, this also allows us to insert MP3s efficiently - ID3 tags are in > a header, not in the main stream, so have a client split the file up into > headers and the main stream, and we avoid duplication caused by different ID3 > tags on the same track, while not requiring a custom client to retreive them. > Probably many other examples could benefit from such a scheme.
I didn't understand the purpose of the short buffers when you first explained them; it'd probably just be best to say in the header of the CD-recipe file to what block-size the individual files needed to be padded out to, and have the client do that itself. As for pulling ID3 tags out of MP3s, that'd still require a custom client (which understood MP3s) to insert them, and that's where the main problem is with lack of collisions. (Aren't ID3 tags at the end of the file anyway, so normal spliftiles would only diverge on the last block...) Thelema -- E-mail: thelema314 at bigfoot.com If you love something, set it free. GPG 1536g/B9C5D1F7 fpr:075A A3F7 F70B 1397 345D A67E 70AA 820B A806 F95D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011105/3f5fca1d/attachment.pgp>
