[tahoe-dev] zfec right for me?

[Zooko O'Whielacronx]

On Mon, Apr 11, 2011 at 12:12 PM, Jack Lloyd <lloyd at randombit.net> wrote:
>
> I did know that zfec does have a header (there is an example encoder
> that produces zfec-compatible output in the fecpp sources), but the
> problems (as I perceive them) with the header were that the padding
> bytes had to be known prior to writing the output (ie, you need to
> either buffer the entire dataset, or use a seekable medium),

Oh right, you have to know the *length* (but not the full contents)
before you know the padding. Good point.

> you can't
> modifiy the block size,

Oh, hm. Another good point.

> and the bit-packing scheme used to encode k/n
> is absurdly complicated for something that will only save 2 bytes.

Well that's definitely true.

> I've attached the format spec as I wrote it circa 2009. Some of this
> may state things which are patently untrue about zfec-in-2009 and/or
> zfec-in-2011; if you spot such falsehoods please point them out. It's
> also never been implemented, so it may be proposing things which
> are foolish, impossible, or both.

I don't spot anything wrong in a quick glance. Again I think zfec
augmented with your formatting improvements and libchop would be a
good match for one another.

Regards,

Zooko