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