On Tuesday 14 January 2003 21:31, you wrote: > Gianni Johansson <giannijohansson at attbi.com> writes: > > I want to make the following changes to the SplitFile metadata spec: > > > > 0) Optional CHK checksum of the entire file. > > SplitFile.CheckSum=CHK at blahblah blah > > Why not just put this into the Info.* metadata? There's already this > place for it. It's a good thing to allow authors to put the Checksum > in the metadata, but I'm not certain that it belongs in the > SplitFile.* section. > Sounds ok to me as long as it's an optional field.
> > 1) Specification of cipher used for all block CHKs > > SplitFile.BlockCipher=TwoFish > > I'm opposed to this for the reason that it will make splitfile > processing a node-only procedure, when it rightfully lies outside the > realm of the node's influence. I don't understand what you mean by this. I just want to make sure all the info I need to re-insert blocks is in the SplitFile, without having to make unspec'd per client assumptions. > > > 2) Explicit requirement that block CHKs contain data only. > > i.e. so if you know the cipher and you know the block size and you > > have the data, you should be able to reinsert the block without any > > further information. > > This is a hard one. It is/should be *extremely* recommended that all > CHKs contain only data and no metadata. I admit that I can't see a > use for splitfile pieces to have any sort of metadata, but that > doesn't mean that there isn't one. If someone inserts a splitfile > with metadata in the CHK blocks, they deserve having their splitfile > be not easily re-insertable, If I follow the spec, I deserve to be able to write a client that re-inserts missing blocks too. I can't if we don't spec that at least for the case of redundant SplitFiles, blocks are data only. > but I don't see any need to label what > they did as "invalid" or as being outside the spec. > > > 3) Explicit requirement that trailing blocks are zero padded to the block > > size. > > I'm against padding trailing blocks; It's needed for FEC, it's a waste > of space otherwise. It would be fine with me if this were spec'd for redundant SplitFiles only. > > > 4) Explicit segmentation in the SplitFile metadata. > > The FEC encoding stuff already "segments" large files. FEC encoding is > > only done over the data in each segment. I want to make this explicit in > > the SplitFile metadata. i.e. > > I see what you're doing and why you're doing it, I'm just not sure > that I like having the extra layer for regular splitfiles. Splitfiles > are a really simple thing, and should be kept as simple as possible. My only real motivation was to make it easier for people who are writing their own FEC SplitFile handling code from scratch. People who use the FCP FEC commands shouldn't have to deal with the grotty details of SplitFile metadata. > > <SNIP example> > > > What do people think? > > > > -- gj > > As an alternative to explicit segmentation, why not just build a > heirarchical splitfile? i.e. have as your main document a > meta-splitfile, where each block is a FEC splitfile. This keeps > normal splitfiles as they should be, while the structure of the > metadata is able to accurately represent what's going on at the lower > levels. This doesn't seem simpler to me. > > Thelema _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
