Gianni Johansson <giannijohansson at attbi.com> writes: > It's good to make the distinction because if you manage to get all the data > blocks you don't need to decode at all.
Prefering data blocks to check blocks will restrict the usefulness of FEC, as it will make the check blocks less popular, thus less fetchable, in extreme degenerating to non-FEC splitfiles. I'm with Fish in the belief that all blocks should be requested in random order, and with equal probability. Decoding is a really cheap operation relative to the fetching of the blocks from Freenet. We shouldn't shun it and make FEC less efficient in the long run. > Client writers just don't want to deal with it. It's certainly a class harder than fetching a monolithic key. I also found that accurate documentation more accessible than the source is nonexistent. > FEC support has been in CVS for almost a year and you are the first > person who has attempted to write a client besides me. Well, could have something to do with Freenet being largely unusable for retrieval of bigger files in that time period. With the current comeback, more freesites are a-coming, with more FEC splitfiles, so the need for clients supporting that rises as well. The FCP access will surely be a good thing. As long as direct access is still possible ... and I don't see why that should be removed. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020912/9f22f076/attachment.pgp>
