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

Reply via email to