summaryrefslogtreecommitdiff
path: root/Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm')
-rw-r--r--Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm80
1 files changed, 0 insertions, 80 deletions
diff --git a/Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm b/Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm
deleted file mode 100644
index e116429abb1..00000000000
--- a/Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm
+++ /dev/null
@@ -1,80 +0,0 @@
-<?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>