>Regarding zip files (you might want to avoid 'jar' which means Java >archive)...
well, okay, we have some archive formats to choose: JAR + hmm.. no improvements to ZIP i suppose: - same as ZIP, redundant - has the directory META-INF in it, which some nerd may abuse to locate /some/mystuff.zip/META-INF/some - java only, but if ignoring the ".jar" is simply a ZIP ZIP + standard in any language on any platform + 100 files to one + compresses + comes with java TAR - semi-standard (linux only) but may be reimplemented + 100 files to one TARGZ - semi-standard with a much larger amount to reimplement + 100 files tp one + compresses RAR - no standard (sigh), no libraries, maybe no documentation or sources to be able to reimplement it? + 100 files to one + best compression so my vote goes to ZIP.... which is nearly the same as RAR, is cleaner than JAR and combines the best of TAR and GZ, without any drawbacks, comes right with java and ist widely spread >... >> Redirect.Target=freenet:SSK@some/some//mycommon.zip/next.gif >> Name=next.gif >> ... > >Why not simplify this and avoid redirects altogether... > >Let's use the file extension .FproxyArchive > >Fproxy should... > >- look for *.FproxyArchive/* >- Use freenet to retrieve *.FproxyArchive >- Fproxy should cache it >- It should serve to the client the requested file from within the >archive well, this is really a hack ;) combining mime and fileext would result to the approach i posted last week loosing mime would complicate determination of the archive's internal format (zip, some other plug-in-encoder, format-XYZ?) loosing fileext would not harm, as long as the mime is present and correct determining a file's content on it's filename is bad IMHO, but mimes may be tampered, too, so i have no other argument as "hack which makes us loose other comressions if we do not use another fileext" and "dirty hack, dirty hack, dirty hack" >This may provide less flexibility, but it is easy to understand, results >in fewer files does it?! >and would be easier for insertion wizards and so on. no it does not. inserting a line of Info.Format or Info.UseAsABundle into the map file or simply renaming the file is nearly the same from the program's view >The is just an idea, and I realise it may seem like a hack putting this >in the key rather than expanding the metadata that we already have... >but it is also the simplest way, and I think other schemes could do with >being judged against this as a baseline. In order to work with all key >types, it might be best that ".FproxyArchive" was appended when why "FproxyArchive" ?? is it "Fproxy FEC" no.. bundling files to archives is completely unrelated to fproxy, so please do not use it's name for it! >referring to the key, but not actually expected to appear in the >retrieved key name. > >Regards, >Greg Harewood nice to have another idea :) (although i do not like it very much :D) i would like to see some comments from ian and oscar, but they only seem so ignore the support mailing list, without knowing thar be little suckers have no way to post our mails to tech or devl. matthew's opinion would be nice, too, about his ZIP@ and his opinion on metadata modifcation ____________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
