"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > >Is there any particular reason why the tool would do that on it's own? The > >node already has to do it regardless (am I correct in thinking that?), so > >doing it twice is wasteful.
The node should not do any data compression; that's completely a client issue. > > adding a hypothetical FCP parameter like "tryToCompress=false" would > force the node to not try to compress the stuff and thus tools could > compress the data by themselves using faster and/or native > routines/hardware. The node will not be compressing data for people; it's definitely better to have clients that support compressed keys, but the node should stay out of the way of this kind of thing, as it just needlessly complicates the node. And we all know fred is complicated enough. > also, 3rd party *nodes* will have to reimplement at least the > decompression side to allow the user to use freenet. this might not > be a big problem if we try to use widely spread algorithms like > standard zip, which has a library at hand in nearly every computer > language. try to use an algorithm that is available for the mayot > programming languages like c, cpp, java, delphi, python, .... i > myself have not looked for support of bzip2/... in these languages, > but i'll bet the chances are better that standard zip could be found > within a lib. > Use zip; it's *very* standard and easy to use. and the difference in compression isn't that big of a deal. > another topic is the hash of the compressed data. even if we can > agree on the used compression algorithm, the *implementation* of > this alg might differ between languages and even language versions. > this might lead to the effect, that compressing the *same data* > leads to *different archives*, which will of course produce > different hash keys for the compressed data Yup, this is the colliding CHK problem, and if compression were in the node, every node reimplementation would have to match fred's quirks exactly. Whereas if it's a client function, they can be looser about handling data, as long as they all can write something that's understandable by the other clients, that's good enough. But nodes need to produce the exact same CHK for the same data. > > > just my 2 eurocent, maybe i'm worrying too much... > You are. If you want something to happen on this issue, write some code for your favorite client(s) to use zip compression. 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:8080/cgi-bin/mailman/listinfo/devl
