diff options
Diffstat (limited to 'Build/source/libs/zziplib/zziplib-0.13.58/docs/future.htm')
-rw-r--r-- | Build/source/libs/zziplib/zziplib-0.13.58/docs/future.htm | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/Build/source/libs/zziplib/zziplib-0.13.58/docs/future.htm b/Build/source/libs/zziplib/zziplib-0.13.58/docs/future.htm new file mode 100644 index 00000000000..e116429abb1 --- /dev/null +++ b/Build/source/libs/zziplib/zziplib-0.13.58/docs/future.htm @@ -0,0 +1,80 @@ +<?xml-stylesheet type="text/css" href="sdocbook.css" ?> +<section> <date> 15. July 2002 </date> +<h2> ZZIP Future </h2> What next to come. + +<section><!--border--> +<h3> ZIP-Write </h3> + +<P> + Anybody out there who wants to program the write-support for the + zziplib? Actually, I just do not have the time to do it and no + real need to but I guess it would be nice for people as for + example to spit out savegame files in zipformat. The actual + programming path is almost obvious - start off with the zziplib + as it is, and let it open an existing zip-file. This will parse + the central directory into memory - including the file-offsets + for each file. Then, truncate the zip-realfile to the place that + the central-dir was found (identical with the end of the last + file). If a datafile is opened for writing, either add a new + entry or modify the start-offset of the existing entry to the + end of the zip-realfile - the old data is simply junk. Then + init zlib to do the deflation of the data and append it to the + current zip-realfile. When the zipdir-handle is getting closed + from write-mode, the zip's central-directory needs to be appended + to the file on disk. This coincides with creating a new zip-file + with an empty central-directory that can be spit out to disk. + During development, do not care about creating temp-files to + guard against corruption for partial writes - the usual application + will use the zziplib to create zip savegames in one turn, no + "update"-operation needs to be implemented like exists in the + standalone zip command utilities. +</P> + +</section><section> +<h3> readdir for subdir inside zip magicdir </h3> + +<P> + See the notes in the first paragraphs of <a href="zzip-api.html"> + ZZIP Programmers Interface</a> description. It would add some + complexity for something I never needed so far. The question + came up with using zziplib as the backend of a dynamic webserver + to store the content in compressed form possibly through the + incarnation of a php module - and some scripted functionality + that walks all directories to index the files hosted. I'm not + going to implement that myself but perhaps someone else wants + to do it and send me patches for free. +</P> + +</section><section> +<h3> obfuscation example project </h3> + +<P> + A subproject that shows <b>all</b> the steps from a dat-tree + to a dat-zip to an obfuscated-dat along with build-files and + source-files for all helper tools needed to obfuscate and + deobfuscate, plus a sample program to use the obfuscated + dat-file and make some use of it. Along with some extra + documentation about 20..40 hours. Don't underestimate the + amount of work for it! (otherwise a great student project). +</P> + +</section><section> +<h3> zip/unzip tool </h3> + +<P> + The infozip tools implement a full set of zip/unzip routines + based on internal code to access the zip-format. The zziplib + has its own set of zip-format routines. Still, it should be + possible to write a frontend to the library that implements + parts (if not all) of the options of the infozip zip/unzip + tools. Even without write-support in zziplib it would be + interesting to see an normal unzip-tool that does not use + the magic-wrappers thereby only going off at plain zip-files. + On the upside, such a tool would be smaller than the infozip + tools since it can use the library routines that are shared + with other tools as well. Again - don't underestimate the + amount of work for it, I guess 40..80 hours as there is a lot + of fine-tuning needed to match the infozip model. +</P> +</section> +</section> |