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

   1 # 2017/02/27
   2
   3 ## 07:24
   4
   5 So the record store system is going to be simple in design for the most part.
   6 I am not going to do super complex huffman compression to shave some bytes off
   7 it will just be a simple database. I do however have to have it managed by
   8 blocks. So the thing is then, are records looked up in a map or are linear
   9 searches done. It could vary how they are used.
  10
  11 ## 08:56
  12
  13 Ok so, there will need to be a connection to the record store manager of sorts
  14 and it must have a reference to the local suite that is currently running. So
  15 it makes me wonder, where is `MIDletIdentity` used? Only for IMC currently. So
  16 I suppose the system service to be created is `RecordStoreManagerConnection`
  17 or `RecordManagerConnection`. This will just be for the most part a class that
  18 manages the databases directly. Or better yet not a connection, but just a
  19 manager.
  20
  21 ## 09:05
  22
  23 When it comes to `RecordManager` on the kernel side it will be as it is, but
  24 on the client side it would probably use IMC to communicate with the kernel
  25 or similar as another service. But the methods used would pretty much be the
  26 same for the most part.
  27
  28 ## 18:02
  29
  30 So what I need to do is to have a kind of assigning. Basically I need to
  31 identify with the manager that this is a certain MIDlet. Basically there would
  32 just be a self identity. I suppose all method calls would require an
  33 identifier so to speak.
  34
  35 ## 18:19
  36
  37 For the manager I could just not care about the local MIDlet. Or just use it
  38 implicitly from the `RecordStore` itself.
  39
  40 ## 22:36
  41
  42 At the basic level, I am going to have it where everything is managed by the
  43 record store manager. Perhaps though. I do not want to write what modifies the
  44 records over and over again for each implementation. I want that basic block
  45 like interface that I described before where all records are stored. The only
  46 issue is then I will need a connection interface or class then. But that
  47 varies. So that means the following: I have a problem. Accessing the raw
  48 record store bytes should be left to the kernel and running processes should
  49 use an IMC interface to interact with records. But at the lowest levels I want
  50 every storage format to use a fixed binary interface. So this means that I have
  51 the connection interface that can be created by the implementation of the
  52 record store, but one where an actual binary backed one can be done. So this
  53 would essentially be an `openConnection(RecordStoreOwner)`. The file based one
  54 will for the most part just use a pre-existing (in the RMS package) class
  55 which does all the binary stuff using another given interface. Then on
  56 SquirrelJME, running processes will use an IMC based one. So I suppose then
  57 that the classes should be renamed. Instead of `RecordStoreManager` it is
  58 instead `RecordClusterManager` which opens connections to `RecordCluster`
  59 abstract class or interface.
  60
  61 ## 23:10
  62
  63 This will be a slight problem. `Class.getResourceAsStream` in Java SE does not
  64 match how Java ME 8 looks up resoures. Basically, if I merge the classpath
  65 together as one then it will just look in the earlier JARs for the manifest.
  66 So what I will need to do is simple although it has a very high potential of
  67 not working or completely breaking things. I would have to juggle with
  68 classloaders which in most cases will not work at all (it is a very buggy
  69 system), or I can just set system properties which can specify application
  70 property overrides. The app property overrides would be the simplest to do
  71 because otherwise the simple hosted launch system may become overly complex
  72 while causing more issues than it fixes.