Re: [Duplicity-talk] zfec v s. par2 (and, hello there!) (was: Announcing D éjà Dup)

[Peter Schuller]

> Consider also using zfec [1], a library that I maintain.  It has a  
> Python bindings and it is actively used in the Allmtydata-Tahoe-LAFS  
> project [2], and the flud project [3], at least.  zfec is based on  
> the long-standing, widely used "fec" library thanks to Luigi Rizzo  
> and many contributors over the years.  It seems to be much faster  
> than par2 for a few experiments that I tried (documented in the zfec  
> README.txt), but it is possible that I was using par2 wrong.

Looks a lot better than using par2, which would probably end up being
dependent on the command line tool.

I have not looked into zfec in detail yet, but the one downside seems
to be that (and please correct me if I am wrong), it cannot be used to
produce error correction data separate from the input data. For the
purpose of duplicity it might be nice to support reading the data
without use of the error correction library.

I still want to tackle this, but again I want to do some design
changes to the way backends handle file I/o before jumping onto the
FEC problem.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

pgpLHK7xZTm0g.pgp
Description: PGP signature