On Friday 01 Aug 2003 19:44, Tom Kaitchuck wrote: > So there are three possible solutions. > > A: Have the insertion utilities archive and compress by zipping. Have Fred > compress by zipping. Yields good compression. Requires no major changes to > Fred. Requires no changes to FProxy. > B: Have the insertion utility archive by taring (no compression). Have Fred > compress by zipping. Yields better compresion ratios. Requires no major > changes to Fred. FProxy needs to be able to read tars. > C: Have the insertion utility archive by taring (no compression). Have Fred > compress by Bzipping. Yields best compression ratios. Requires adding > Bziping compressing/decompressing code into Fred. FProxy needs to be able > to read tars. > > OK, does that some things up? Now everyone vote and end this infernal > thread. I vote for B.
I agree with the B vote... Mostly... 1) Compression should be handled in the client (i.e. fproxy in this case), not Fred. 2) Given the recent compression findings, I think I can live with using zip for compression, seen as the library is already built into the standard JVM. 3) There is no point in using tar separately when zip will do it's job just as well, with the additional benefit that zips don't have to be completely decompressed to retrieve any single file, unlike tar based compression approaches. If archives are to be used, and there seems to be a lot of calls for using zip for compression, then let's just use zip for everything and be done with it. 4) Insertions/retrievals through fproxy should be changed to perform the necessary compression/decompression operations for single-file compression, as discussed previously, in a transparent fashion. This probably means tagging the data somehow because a file that is uploaded as zip should be treated differently to a file that was inserted as a normal file. When retrieving a zip, the file should come back as a zip. When retrieving a text/html file, it should come back as text/html, even though it is compressed within the network. Are there any objections to the above spec, other than objections to using any non-manual compression? Gordan _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
