>> Compress a 60k JAR of HTML to 6k and insert it. Then, retrieving any of >> the HTML pages gets you all of them. >> Insert the small images that appear on more than one page as a group >> again, which may be 150k or so, and insert it so that retrieving any of >> those common images gets you all of them for the site.
>All this is good. We just have to implement <ZIP key>//<file in ZIP>, >and all of this becomes possible. well, we had the top of this mail now 100 times.. maybe everybody now realizes that bundling files which belong together might lead to a good idea.... ---~~--- but matthew, why your approach with ZIP@ ? why not use oskar's approach with metadata information which makes *far* more sense to me. ZIP@ is stupid, because the data contained within the archive does not need a special key - it's a file just like any other file, so no special key is needed > OK. Proposal: > Currently manifest sites use Redirect.Target=<some key> or DateRedirect > (which has .Increment, .Target and .Offset). > Add ZIPRedirect: > ZIPRedirect.Target=<some key, which is a ZIP> > ZIPRedirect.Filename=<filename within zip to extract> redirections may work but i think it's the wrong approach, too. it's simply not transparent enough. so every file which resides within the archive must be indexed with a ZIPRedirect.Filename param, which will simply be a too big workaround for embedding archives my idea would be based on metadata information, too, but would look like this: >> Version Revision=1 EndPart [...] Document Redirect.Target=freenet:SSK@some/some//mycommon.zip/next.gif Name=next.gif Info.Format=image/gif EndPart [...] Document Redirect.Target=freenet:CHK@blablaarchivefiledata Name=mycommon.zip Info.Format=application/x-freenet-site-archive (or application/x-zip or whatever archive format fproxy/etc should be able to understand) Info.UseAsABundle=true EndPart [...] End << notice here the additional field "Info.UseAsABundle", set to "true" (default "false"). this enables the client to see that the file the "Name" fields describes is an archive (and not a "directory") which can be opened to retrieve files like "mycommon.zip/next.gif" from within the archive. everything else on the metadata remains untouched, no new key types are needed. [[[ i'm not very good at metadata discussions, but maybe this is a way you can gather some clues from? ]]] ---~~--- >It could be worth discussing whether fproxy should be caching the data >contents itself, or reextract the bundle every time (counting on the >DataStore to cache it). we have a temp directory, use it for extracting the archive (maybe if >n files are going to be retrieved from the archive, otherwise do not expand the archive into temp) this will leave some files lying around, i know. so maybe it's wise to extract the files into the datastore (using their own CHK, not the archive's) so the first look can go into the DS, if the requested file is not present, look into the archive, and possibly extract the file found into the DS, where it is cached when the file is requested the next time. ---~~--- comments? ____________________________________________________________ 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
