> >> >I understand where you are coming from, and at the moment I am fairly > >> > evenly split between considering zip vs bzip2. > >> > >> please try to stick to plain stupid zip if you have to. > >> not only because it's been around with the jre for some time, so we can > >> assume it's mostly bugfree, but mainly because i worry for 3rd party > >> freenet nodes. > > > >It would not lead to 3rd party nodes at all. Because the compression is the > >matter of a client-side protocol, in order to extract the data from the > >network, all clients would have to support the (de)compression algorithm. > >Therefore either everybody uses it or nobody uses it. There is little scope > >for compromise inbetween because all compressed files will not work for the > >people who don't have the node with the codec. So, IMHO, it comes down to the > >choice between better compression, and the convenience of a built-in library. > > > >Gordan > > >It's not in the node. It's in the client code. Which can work over FCP. > >So you can reimplement the node without reimplementing the client code. > >So it's no big deal. > [Toad] > > then perhaps i misunderstood the approach. > > i believed the container compression has been cleared by introducing the code from fish; supporting jar and standard zip files? > > by the way, you are using jar-specific classes to access the container ingredients: > + JarInputStream myJis=new JarInputStream(myIs); > + String containerMeta="metadata"; > + // because we don't have access to a File object, > + // we have to skip through until we hit our filename... > + JarEntry ent=null; > but you also allow the zip mimetype for container digging... is it applicable to use JarEntry and JarInputStream on zip files??!?
Yes, a jar is a zip and JarInputStream extends ZipInputStream.. /N _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
