assets/developer-notes/stephanie-gawroriski/2017/02/26.mkd

   1 # 2017/02/26
   2
   3 ## 13:40
   4
   5 I will need a way to get the running MIDlet.
   6
   7 ## 13:52
   8
   9 Starting with exceptions should be easy.
  10
  11 ## 14:30
  12
  13 I have the following blank projects:
  14
  15  * meep-cellular
  16  * meep-concurrency
  17  * meep-event
  18  * meep-io
  19  * meep-liblets
  20  * meep-power
  21  * meep-provisioning
  22  * meep-securityframework
  23
  24 Just hope a bunch of those are simple.
  25
  26 ## 14:51
  27
  28 One nasty thing is that record stores use checked exceptions.
  29
  30 ## 15:02
  31
  32 The fun thing will be keeping the record database up to date with multiple
  33 processes being ran. SquirrelJME will need some way to synchronized one file
  34 with another even when multiple SquirrelJME processes are being ran.
  35
  36 ## 15:08
  37
  38 Going to say that RMS sucks. The API is quite nasty, has a bunch of
  39 inefficiencies and just screams badly designed.
  40
  41 ## 15:17
  42
  43 For sanity purposes, I am probably going to need some internal file locking on
  44 paths and file channels. Or I could just ignore multiple SquirrelJMEs running
  45 at once and just treat the database as if it were opened only by a single
  46 running program. This is since all processes running in SquirrelJME will be
  47 under the same process.
  48
  49 ## 16:22
  50
  51 I only want to write the record handling code once, so that means I will want
  52 a generic block based representation of the database records that can persist
  53 within SquirrelJME.
  54
  55 ## 17:00
  56
  57 Typing up all those classes took awhile, about 4 hours.
  58
  59 ## 17:22
  60
  61 Also, I forgot that today was SquirrelJME's birthday! Happy birthday! I have
  62 worked on it for an entire year.
  63
  64 ## 17:49
  65
  66 So I will need an efficient and nice API for records. There would be a single
  67 instance of the database. Which reminds me to check meep-io and see how much
  68 it differs from GCF.
  69
  70 ## 17:52
  71
  72 So what does that give me then? I would have each record store that exists for
  73 an application be a single block of binary data where records are stored. So
  74 there would need to be a record store manager. Every suite stores its own
  75 records, so that would need some kind of lookup. Then there can be multiple
  76 stores for applications.
  77
  78 ## 18:07
  79
  80 Probably would be best to roll my own format than use a pre-existing format
  81 because I am not even sure that they exist.
  82
  83 ## 18:21
  84
  85 Dreamcast memory card blocks are 512 bytes in size and the Nintendo 64 has
  86 2048KiB pages about (supposidly). My database would be an ultra-compact
  87 database. Simple in concept and hopefully fast enough to not be really slow. I
  88 suppose it should be transactional.
  89
  90 ## 18:25
  91
  92 So inventing such a format will be interesting to say the least, but it could
  93 potentially be done.
  94
  95 ## 18:58
  96
  97 I do wonder if I can do obtuse and convoluted tricks to reduce the size
  98 representation of keys. I can swap bits and use huffman encoding for the id,
  99 tag, and the size of data stored. Most records would be stored in very small
 100 quantities so as long as the huffman table even for the data that will not fit
 101 where it only uses that amount of data to be stored. That would complicate
 102 things but potentially reduce the storage space.
 103
 104 ## 19:11
 105
 106 That would probably reduce the required size, but that would complicate things
 107 a bit. So I do not want to overcomplicate things needlessly for a few bytes.
 108 If I do need to shave off bytes like this, I can always have a secondary
 109 format that treats this way.