summaryrefslogtreecommitdiff
path: root/Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm
diff options
context:
space:
mode:
authorPeter Breitenlohner <peb@mppmu.mpg.de>2012-03-12 13:09:04 +0000
committerPeter Breitenlohner <peb@mppmu.mpg.de>2012-03-12 13:09:04 +0000
commit17d564c8150295febbac9174757862eaccf9bd89 (patch)
treebc5d40c76e6b8d0f9a5aa216296b8b406cb6426f /Build/source/libs/zziplib/zziplib-0.13.62/docs/future.htm
parent2386c1184c15a8ee1fb679e2de49b5972d3d179d (diff)
zziplib 0.13.62
git-svn-id: svn://tug.org/texlive/trunk@25615 c570f23f-e606-0410-a88d-b1316a301751
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, 80 insertions, 0 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
new file mode 100644
index 00000000000..e116429abb1
--- /dev/null
+++ b/Build/source/libs/zziplib/zziplib-0.13.62/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>