07:11
One thing is, should the interpreter just be an execution engine or should the kernel be associated with it so it may do things. I would suppose that it should just be an execution engine for the most part.
07:54
I believe the recording file should likely be in ASCII rather than binary, this way it is easier to look at for example. It could also be manually adjusted at the risk of causing desynchronization.
07:58
However, ASCII would make it less dense.
08:42
Before I go into the rerecording interpreter, I should instead write the standard interpreter first. The standard interpreter would be much faster to begin with anyway. However, once it is written I can write and implement the entire class library which will take some time. However, I have a base layout used for the rerecording interpreter.
13:32
Thinking about the UI code, I believe I will simplify it. Instead of having
native widgets and such, I will just draw and handle events in a framebuffer
or text console for example. The basic UI drawer will be very simple, but
there could be the potential for custom UI drawers and such. So displays would
be created, but there would then just be a plain framebuffer with my own
drawing code. Then if an interface supports it, it can take all of the stuff
within the framebuffer and provide an overlay drawing which makes it appear
more native for example. So the drawers will be basically be just: simple,
console, and native. So displays as before would be used and such. Widgets
could be added to displays and displays could be made displayable on the screen
also. The only issue would be menus and such on Mac OS and Mac OS X, however
that case could be handled. Thinking about it however, menus would be purely
handled by the native interface (unless it does not support menus). If menus
are not supported and menus are used then a menu bar would appear at the top
of the display.
13:42
So the native feel would only be created by a customized drawer or interface over the widgets. I would then have a consistent user interface across platforms.
13:51
This display interface may have to be exposed either via IPC or via
__squirreljme. Having it under IPC would be cleaner for example. Due to the
various differences in screen size across devices, I will need to potentially
use a floating point based pixel layout. Likely just float however. The units
I suppose would be either cm or mm. A display would be requested with a
given amount in cm, so I suppose cm would be the most consistent when it
comes to widget placement. When it comes to the deterministic interpreter,
what it displayed on the screen must be deterministic. So this means that the
UI manager would have to be a process which is interpreted also. When it comes
to the deterministic interpreter, the idea is that system calls are recorded
in the stream and their values are returned. So really the UI part can be
somewhat native. However, separation would best be done. The launcher would
have to run as an interpreted process. However, actual display surfaces which
provide pixel level access could be created and exposed over __squirreljme.
So instead, displays are actual drivers which may expose terminals or
graphical displays. So instead of just IPC, drivers could be polled by any
program running, then depending on their permissions they could interact with
the driver. I suppose for a common sharing, the IPC and driver set could be
merged together in a way. So an IPC socket would be created to a driver which
would be provided by the kernel, in this case it would create a video display
and use float cm to measure everything. Anything sent over the IPC in the
standard interpreter would be passed as is. Under the rerecording interpreter
the messages sent will be sent as is, but the received messages would be as
they were recorded previously. So the kernel driver would act upon the client
IPC but the client processes would completely just ignore anything that was
sent back.
14:10
With no potential for pixels amounts and only cm amounts to be transferred, this means rerecord playbacks will generally appear the same varying on the resolution of the device. This means that the super massive 4K displays would be supported also (since they have a higher pixel density). Then for Palm PDAs, the high density displays will accordingly be handled also.
14:12
This means I must define the IPC interface in __squirreljme. Then the
launcher would use this interface accordingly while it is interpreted itself.
The launcher would have its own display, but it would be given the power to
launch other processes. That could be handled by the IPC interface too, so
in the event that the launcher is running on a rerecord with a differently
ordered set of JARs with more or less, provided all the JARs are there with the
given keys they would still be found.
14:26
The getResourceAsStream could also be done via the IPC interface too for
simplicity.
15:56
Setting up of the launcher can be performed by the actual launcher code. Then the user interface can become a simple display server with the potential for widgets as described before.
19:31
Thinking about it, only the launcher would be run as a given process. What I need however is a callback which can be assigned to a kernel before it starts which initializes the display server socket that the launcher and normal programs would use for example. For simplicity the display will just have a single set of widgets to it which may be added for example. Although I should most likely have more complex scenarios. However, displays should only be locked to themselves and not others. Displays could be running as the server or there could be a client interface which is used.
19:39
One problem though is the difference in client and server IPC interfaces.
I would have to duplicate both of them. However what I can do is have IPC have
the ability to be used with a kind of alternative socket backend. If one is
specified, instead of calling the statics which would equate to system calls,
the others are used instead. This would then allow me to share the IPC client
and server in __squirreljme yet have a variant which can handle being in the
kernel. Then I can have a UIServer and a UIClient which use the sockets
accordingly. Then UI elements would be bridged by a client and utilized by
a server to display what the client desires in most cases. This would allow
for just a single set of classes to be used. A server specific drawing
interface could just read from a UIServer it hosts to display widgets.
20:19
What I need though is a good way to specify services which should be started
by the kernel before code runs and such. The code may need to for example
start the filesystem server or the UI server for example. Also the
BootInterpreter class could also potentially be commonized into the launcher
code. The launcher will need those details to launch applications anyway in
the kernel. If the system specific stuff just concentrates on starting the
launcher then I can have a single common handler for stuff such as the command
line. So the launcher would be initialized in the executive environment. The
launcher which is being interpreted or natively executed can then listen on
an IPC socket which provides a launching service to run other programs and
such. So the launcher would be given then command line arguments for
parsing. It then looks at the classpath provides which were associated with
the kernel. The class unit providers would have to be added as an argument
that could be used. Another alternative is for the kernel to listen to a socket
and then the first connection would be the launcher, once that is connected it
would accept no other connections. This would then be the direct interface that
the launcher uses to have the kernel start programs, UIs, and such. So it would
act as an early boot interface of sorts. Then with it done this way, the
launcher can remain a user-space process which does not have elevated powers.
This would be far better in terms of security and stability. This would also
mean that the kernel would be mostly just a pass through interface with thread
and process management. This IPC bridge would then allow the launcher to
easily be interpreted and would not require magical kernel interfaces to be
implemented.
20:32
This then means that the launcher does not even need to depend on the kernel at all. It also does not need the class-path project either because the units which are made available are provided by the kernel.
20:36
Then this also means that command line handling is also associated with the
kernel and that handles command line switches. This also means that for
specific systems where there might not be a command line normally, it can now
be specified in a general means. Then with this, the BootInterpreter class
is not needed at all, Main will just initialize the kernel and then run the
cycles on it.
21:43
Jupiter again shines in my window. This planet appears much.
22:02
If I sit up from laying, there is another light visible just above the horizon. That dot is Mars, then just above that to the left is Saturn but it is too faint to be seen.