Matthew Toseland <[EMAIL PROTECTED]> writes: > > > > > 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. > Why can't the client do the padding with nulls for the last data block, > if it's not already done?
The node is responsible for spitting out the same data that was inserted; issues such as padding (which the node already does) don't need to become a client issue. i.e. if I want a splitfile that's not n*2^k bytes in size, I shouldn't have to send the node more data to insert when that data isn't really part of the datastream. > > 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. > It would be good to support splitfiles inside non-redundant splitfiles, > at some point. BUT explicit segmentation inside a splitfile makes > more sense than splitting it out into another splitfile, simply because > of the delay involved in fetching another file in series. I agree that delay is bad, so there's a cheap trick that'll still give this result without resorting to multiple cdocs; have each segment be a different name within the same splitfile, and have the document reference other parts of itself for instructions on how to download the redundant segments. I'm thinking about having the following inserted as SSK@blahblah1/hugesplit: Version Revision=1 EndPart Document SplitFile.Size=30000000 SplitFile.BlockCount=3 SplitFile.Block.1=SSK@blahblah1/hugesplit//part1 SplitFile.Block.2=SSK@blahblah1/hugesplit//part2 SplitFile.Block.3=SSK@blahblah1/hugesplit//part3 EndPart Document Name=part1 SplitFile.Size=10000000 SplitFile.BlockCount=20 SplitFile.CheckBlockCount=10 ... (part1's redundant splitfile metadata) EndPart Document Name=part2 ... (part2's redundant splitfile metadata) EndPart Document Name=part3 ... (part3's redundant splitfile metadata) End Something like that would be competitive in size with the gj's extension to the spec, and would completely cover what he's trying to do with it. Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl