On Wed, 30 Jul 2003, Gordan wrote: > Here is what I propose. ZIP archives to be replaced with tar archives. Then, > on a lower, "node" level, at insert time, the file being inserted is checked. > If it's mime type or extension are indicative of compressed content, we > simply insert the file as is. We do the same if the node is explicitly told > not to compress the file, e.g. via a flag. > > If the file still appears to be compressible after that (e.g. html, text, > tar), bzip2 compression is applied to the file. The file is compressed and > the pre/post compression size is checked. All files in Freenet are padded to > the next power of 2 limit, so if the file after compression remains in the > same size bracked (padded to the same power of 2 size), there is no point in > compressing it. We just throw away the compressed file and insert it > uncompressed.
You say there's no point in compressing it, but at that point you've already compressed it. I mean, I guess you're saving that little bit of processing power on the eventual receiving end. > This means that compression/decompression overhead is avoided where no > space/bandwidth would be saved due to other design issues. Best of all > worlds, I think. Well, you're not saving "compression/decompression overhead". Just "decompression overhead". Your point remains, though. > However, there is something else I have been thinking about. Tar and bzip2 > would require extra Java libraries. They exist, but they would have to be > bundled with Freenet. This would increase the download size, which is not > desirable. ZIP handling is already built in, and would require no additional > libraries. The downside is that it generally doesn't seem to compress as well > as bz2, and sometimes the difference is quite noticable. Ugh. Bundling issues with the JVM are already a pain in the ass. Bundling sucks. (Although I think there may be a Third Way with regards to this.) > Thoughts please. :-) This sounds like a lot of if-thens. Considering the balance between code complexity/maintainability and clock cycles saved, would it maybe be easier to just say, "Archive and tar everything"? Just simply zip everything, do the before/after comparison you mentioned, and be done with it? Note that the code issue affects not just Freenet Project, Inc. software, but also the job of third party tool authors. They have to implement the receiving end. I guess this depends on this: Where is this going to go? In fproxy? Bad idea, for the reasons above. Fred? Fred is a better choice, since fred is common to every client, and the wheel could be shared. Of course, that'd be transferring the wheel-reinventing to third party *node* authors. Six of one, half dozen of the other. The benefits of zipping data are apparent. I'm just proposing thoughts on how to do it. -todd _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
