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

   1 # 2016/07/31
   2
   3 ## 08:06
   4
   5 Must refactor `DynamicByteBuffer` now.
   6
   7 ## 08:23
   8
   9 I should also refactor and redo the `ZipFile` code also, drop plans for 64-bit
  10 ZIP files and remove the very slow structured reading code. Basically simplify
  11 everything so that it is much nicer.
  12
  13 ## 09:30
  14
  15 One issue with the chunks is that when a byte is added or removed, all of the
  16 chunks following must get their size recalculated. I do wonder if I can avoid
  17 doing that. I am thinking of a binary tree-like structure for this which just
  18 has relative size. It would very well have to remain sorted and well
  19 balanced. It would have to be perfectly balanced perhaps using a red/black
  20 tree. Then chunks would have to be placed in a way where they all represent
  21 a part of the file. However this would be a bit complex. Alternatively chunks
  22 in a given area could be for the part of the file they are a part of. The only
  23 issue with that is moving things over. So things will get complicated when it
  24 comes to buffer management. One thing however, is that there can be cards
  25 associated with a chunk of data. Each chunk has a head and tail for where data
  26 is stored. However since the position...
  27
  28 ## 09:40
  29
  30 ...is not known, cards can be used as a note to where data should be placed and
  31 keep that in a sorted list of sorts. Each card would be associated with a
  32 chunk. However this still complicates things in a way.
  33
  34 ## 10:34
  35
  36 The big slow down would always be keeping the buffer positions valid. Inserting
  37 and removing of bytes would also add some issues. I like the buffer for quick
  38 insertion and removal of data. Perhaps what could be used is a kind of sub-
  39 partitioning scheme of sorts. Actually, I could have Chunks which just manage
  40 data which know nothing of their storage location. Basically, each junk would
  41 be associated with a partition map which does know the positioning. Something
  42 that might be a bit more efficient would be to have dynamically sized chunks.
  43 For example when a bulk write is performed at a location, if there is no room
  44 to store the data in the given chunk then the bulk operation just splits the
  45 chunk at the write position and then creates a new chunk with the bulk written
  46 data. It would write to the appropriate locations on two chunks before creating
  47 a new one.
  48
  49 ## 10:49
  50
  51 The default block size could then just act as a minimum block size. Going to
  52 take a walk and figure something out hopefully.
  53
  54 ## 12:09
  55
  56 Actually something that might work would be a partition list of sorts. A
  57 logical partition location and a physical partition location. Bytes could
  58 literally be written anywhere as long as there is free space somewhere. When
  59 bytes are added to a position, a new partition could be created if there is no
  60 free space anywhere. Then the logical partition information will just point to
  61 where it really is. Removal of bytes would just entail shifting the partition
  62 start/end over accordingly or splitting it. There would need to be two lists
  63 which point to the same partition data, each sorted for logical partitions
  64 and physical ones. However since the data is very much the same, they can share
  65 the same objects. If any bytes are removed then logical partitions that follow
  66 just get their positions shifted accordingly. So this would be like a hard
  67 disk filesystem.
  68
  69 ## 12:14
  70
  71 To simplify things and not require renumbering on large buffers, each chunk's
  72 physical and logical positions would be to that chunk only. Then each chunk
  73 would have a note of the number of bytes that are in the chunk.
  74
  75 ## 12:23
  76
  77 Each chunk would have then have an indicator which says where it is located.
  78 For simplicity all chunks will be linear physically, so a chunk at a higher
  79 index will always have a greater address. If insertion in the middle causes a
  80 chunk to be filled then a new chunk will be created in the middle. So with
  81 the partition scheme, if there are ever any removals a single value just has
  82 to be incremented or decremented (or a partition created). Since partitions can
  83 appear and disappear, it might be best to have a pool of partitions waiting to
  84 be used so they can be reassociated in a chunk. However, they should just
  85 remain to a single chunk.
  86
  87 ## 12:28
  88
  89 It might also best best for the default chunk size to be managed by the
  90 chunk manager itself (unless a system property is used). Using small chunk
  91 sizes such as 32 (the current default) may be a bit inefficient.
  92
  93 ## 13:56
  94
  95 Any refactored ZIP file code should not rely on the full NIO classes so it can
  96 be used by lighter JVMs.
  97
  98 ## 17:22
  99
 100 Something that could work is a contributory setup in a way. That is, similar to
 101 `src` I also have `contrib` where packages can be placed. This way extra
 102 packages which are not part of the _SquirrelJME_ source tree can be compiled as
 103 if they were part of it. This could be used for ports.
 104