Robert Bihlmeyer <robbe at debian.org> writes: > I'd really like to see a FEC algorithm that uses differently-sized > checkblocks, and the benefits that this algorithm actually buys us. > Until then I'm going to believe that this is just an > overgeneralisation. > I agree with you that it's not needed.
> Sounds good. Please don't deprecate BlockSize, just make it optional > (IIRC it already is at the moment). Users of Vandermonde/OnionNetworks > FEC should always insert with this field. > I have no plans to deprecate any fields. > > I think that having multiple algorithms is going to result in either > > noone using FEC or clients implementing their own FEC that's only > > compatible with other copies of that same client. > > I don't think so. If the codec is available in source in an accessible > language (C preferred), under a liberal license, it will be > incorporated into all maintained clients. > that sounds easier than it actually is. very few languages' bindings are easier to use than just writing the code to decode graph style redundant splitfiles[1] > > actually, it's worth quite a lot in terms of future growth; as better > > methods of deciding how to XOR data blocks together to produce check > > blocks are discovered, they can be used without requiring all client > > authors to rewrite their code. > > That's true. But I'm not envisioning changes in FEC technology as > frequent as you seem to. > > -- > Robbe I'm doing my own research in the area, and I can assure you there's plenty of progress to be made. Thelema [1] I'd like to coin the term "rsplit" for this, instead of typing out "redundant splitfile" as often as I do. -- E-mail: thelema314 at bigfoot.com Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
