source/libs/zziplib/zziplib-0.13.62/docs/future.htm

   1 <?xml-stylesheet type="text/css" href="sdocbook.css" ?>
   2 <section> <date> 15. July 2002 </date>
   3 <h2> ZZIP Future </h2>              What next to come.
   4
   5 <section><!--border-->
   6 <h3> ZIP-Write </h3>
   7
   8 <P>
   9   Anybody out there who wants to program the write-support for the
  10   zziplib? Actually, I just do not have the time to do it and no
  11   real need to but I guess it would be nice for people as for
  12   example to spit out savegame files in zipformat. The actual
  13   programming path is almost obvious - start off with the zziplib
  14   as it is, and let it open an existing zip-file. This will parse
  15   the central directory into memory - including the file-offsets
  16   for each file. Then, truncate the zip-realfile to the place that
  17   the central-dir was found (identical with the end of the last
  18   file). If a datafile is opened for writing, either add a new
  19   entry or modify the start-offset of the existing entry to the
  20   end of the zip-realfile - the old data is simply junk. Then
  21   init zlib to do the deflation of the data and append it to the
  22   current zip-realfile. When the zipdir-handle is getting closed
  23   from write-mode, the zip's central-directory needs to be appended
  24   to the file on disk. This coincides with creating a new zip-file
  25   with an empty central-directory that can be spit out to disk.
  26   During development, do not care about creating temp-files to
  27   guard against corruption for partial writes - the usual application
  28   will use the zziplib to create zip savegames in one turn, no
  29   "update"-operation needs to be implemented like exists in the
  30   standalone zip command utilities.
  31 </P>
  32
  33 </section><section>
  34 <h3> readdir for subdir inside zip magicdir </h3>
  35
  36 <P>
  37   See the notes in the first paragraphs of <a href="zzip-api.html">
  38   ZZIP Programmers Interface</a> description. It would add some
  39   complexity for something I never needed so far. The question
  40   came up with using zziplib as the backend of a dynamic webserver
  41   to store the content in compressed form possibly through the
  42   incarnation of a php module - and some scripted functionality
  43   that walks all directories to index the files hosted. I'm not
  44   going to implement that myself but perhaps someone else wants
  45   to do it and send me patches for free.
  46 </P>
  47
  48 </section><section>
  49 <h3> obfuscation example project </h3>
  50
  51 <P>
  52   A subproject that shows <b>all</b> the steps from a dat-tree
  53   to a dat-zip to an obfuscated-dat along with build-files and
  54   source-files for all helper tools needed to obfuscate and
  55   deobfuscate, plus a sample program to use the obfuscated
  56   dat-file and make some use of it. Along with some extra
  57   documentation about 20..40 hours. Don't underestimate the
  58   amount of work for it! (otherwise a great student project).
  59 </P>
  60
  61 </section><section>
  62 <h3> zip/unzip tool </h3>
  63
  64 <P>
  65   The infozip tools implement a full set of zip/unzip routines
  66   based on internal code to access the zip-format. The zziplib
  67   has its own set of zip-format routines. Still, it should be
  68   possible to write a frontend to the library that implements
  69   parts (if not all) of the options of the infozip zip/unzip
  70   tools. Even without write-support in zziplib it would be
  71   interesting to see an normal unzip-tool that does not use
  72   the magic-wrappers thereby only going off at plain zip-files.
  73   On the upside, such a tool would be smaller than the infozip
  74   tools since it can use the library routines that are shared
  75   with other tools as well. Again - don't underestimate the
  76   amount of work for it, I guess 40..80 hours as there is a lot
  77   of fine-tuning needed to match the infozip model.
  78 </P>
  79 </section>
  80 </section>