assets/developer-notes/stephanie-gawroriski/2016/07/09.mkd

   1 # 2016/07/09
   2
   3 ## 14:57
   4
   5 Since I have namespaces, objects and resources when writing to C must be
   6 prefixed by the namespace. However for namespace class exportation, I will
   7 need to have it where I can declare the classes which are in the specified
   8 namespace for global linkage. So essentially there will be a gigantic array
   9 of classes in the given namespace. Then references to these classes are bound
  10 by these namespace lists. Built-in namespaces would be included in an internal
  11 list which then points to the namespace structure data.
  12
  13 ## 17:38
  14
  15 A problem with TAR is that I need to know the size of the file before I can
  16 write it. I may have to instead use streamed ZIP files.
  17
  18 ## 17:43
  19
  20 So basically this will be the ZIP file format then, since TAR would not work.
  21 At least for source code, I would not need permissions or execute bits set.
  22 However, my project called `zip-compression` would better be called `zip-file`
  23 instead. Then I can make a new project which is able to write ZIP files. Since
  24 I do not have any compression currently, I can always add that later.
  25
  26 ## 17:46
  27
  28 Actually it might be best if it were to become `zip-reader-block` for block
  29 based reading of ZIP files. Another variant could be `zip-reader-stream` for
  30 stream based reading. At least for uncompressed streamed data with no known
  31 size, a valid header detected along with a sane size and CRC would determine
  32 if data just blindly matches the ZIP data (say a stored ZIP within a ZIP) that
  33 precedes it. That could be used to determine when an uncompressed streamed
  34 entry with unknown initail size is used.
  35
  36 ## 17:55
  37
  38 Personally, I wonder if the supporting 64-bit ZIP files is worth it. Generally
  39 for Java ME I would only ever use 32-bit ZIPs. Supporting entries that are
  40 very large or ZIPs with lots of files would be more sane than not supporting
  41 it. However, I suppose initially I should have a means where I can read/write
  42 64-bit ZIPs but not yet support it for example.
  43
  44 ## 17:59
  45
  46 I would suppose that the intended targets for Java ME and SquirrelJME in
  47 general, there would really be no need to support 64-bit ZIP files.
  48
  49 ## 18:57
  50
  51 Generally my code itself would likely never operate with very gigantic files.
  52 Also lightening up the code would simplify things. Also one thing to consider
  53 is to remove the data pipe code and just have the deflate decompression be an
  54 input stream of sorts.
  55
  56 ## 19:00
  57
  58 I would suppose that my ZIP stream writer would be rather simple in its
  59 implementation. Generally just need compression or storing. Then I would also
  60 need a CRC32 calculator, but that can be generic in either being an output
  61 stream or an input stream. Right now for the most part I made the data pipe to
  62 allow for buffering and whatnot, however it might not actually be needed much
  63 at all. The only issue would be inflating on an output stream. As in, I write
  64 deflated data. So I suppose instead I could instead of a `DataPipe` would just
  65 be an input and output stream which is very similar. So something very similar
  66 but something very much more direct and less buffered.
  67
  68 ## 19:07
  69
  70 Also one thing to consider is that with the builder, instead of using the
  71 block based ZIP reader I can use the stream based one instead. Since I have to
  72 go through all entries anyway, I do not need to wait for reading the index at
  73 all. However, I suppose for the package code I just need to read a single file.
  74 It may be faster assuming the entries in the ZIP contents have their sizes
  75 before the file starts (otherwise I would be forced to decompress to continue).
  76
  77 ## 19:17
  78
  79 What I need is actually a little endian DataOutputStream for ZIP data.
  80