03:16
A rather large thunderstorm is closing in.
03:59
A very large thunderstorm.
04:32
Taking yesterday's idea, I can have a module based Java virtual machine. Basically the virtual machine is initialized and it searches for modules in the class path. The modules can provide filesystem access and such for example. The modules could also provide execution environments also possibly.
04:40
The JVM at its base can be abstract, where implementations could implement native CPU support and such. So for example process creation and memory management is not handled by the JVM at all but by the implementation.
04:43
Then using the filesystem module, class units that use that filesystem interface can be used.
04:46
The JVM would be given main arguments, setup the launcher, and then just
provide an interface for things. So the JVM would be similar to the kernel
except that it would be far simpler and more modular.
05:06
So JVM and family will just be similar to the kernel, then I can move some
of the PVM code over it. This way there are somewhat common interfaces used
and duplicated code for native implementations would be completely rewritten
from scratch.
05:28
Heard what sounded like a gun shot and the power failed, that would likely be a transformer.
09:28
I believe for the filesystem, regardless of the OS I will use the same
structure. The @ will be the root specifier, followed by the name of the
root. The directory separator would be /. All filesystems that exist on the
host along with virtual ones will exist under this scheme. This would simplify
the very different file system handling across various systems. So for
example on Linux the UNIX root would just @root/ while on Windows C: would
be called @c/. The roots would be case insensitive.
09:36
Not sure about the modules, but it should work.
09:59
Actually for the device I/O, I should use the device I/O interfaces and such. This way I do not invent my own.
11:26
Thinking about it, I am definitely going to need the JVM to depend on the full
CLDC. Well actually, not really. I just need a nice design of the upper layers
that is not very complex. For example, there could be built-in JARs such as
in the class-path package that are purely native, there could also be ones
that exist on the disk somewhere. Processes running on the JVM would be
standalone in that they cannot access each other, except through networking,
IPC, and the filesystem for example.
13:00
Ok, so I have decided that for now JVM will just have default provided class
unit providers. However, another thing I have decided on is having a URI
scheme when it comes to class units. Instead of being identified by a string
they are identified by a URI. The scheme would be the name of the provider.
So for example if the default provider is called default then foo.jar
would be represented as default:foo.jar. When JARs are requested as such
when they are needed for dependencies for example the JVM will search all
registered providers if a namespace is not specified. So if foo.jar is in
the Class-Path attribute then it will search for default:foo.jar. However
if orange:foo.jar was specified then it will look for a provider called
orange and then attempt to get a class unit for foo.jar, which could fail.
Using this scheme, it is possible to have special class units which can be
used for standards and the names of liblets for example. So something such
as liblet:Name%20Of%20LIBlet could be performed perhaps.
13:07
However, doing that would be a bit complicated since when looking for a liblet of a given name it can be cached or have it where the manifests are searched. But, I must implement URIs since those would be very handy to have, and Java ME sadly lacks URIs.
13:14
When it comes to URIs, I need to handle IPv6 and the inconsistent zoneID. However when it comes to parsing a string, if something is a IPv6 literal then it can sanitize the zone ID.
18:03
Thinking about it, the test system could actually use URIs to refer to tests.
Then I can pass arguments to tests and in general permit default tests to
contain more information. Then I would also not need to have test specific
areas be specific. So say that a test requires user input when it comes to
validity, that can just be passed to say the query component for example.
However before I can switch to URIs, I have to implement the URI test first.
Once the URI testing is complete and URIs appear to work I can then switch
the test system to use URIs instead. The URI could be in the form of say
test://package/test-name?anything-extra.
18:09
There could also actually be a standard query and argument set of things that is decoded for a requested test. So when a test is performed, the query and its fields will be read into a map of key/value pairs and passed along with the name of the test to perform.
23:36
For paths in URIs, they should be fragmented and split into units and marked if a path is absolute rather than having a single group for paths. This would make resolution easier.
23:40
Reading up on paths, they can be escaped which means any character is valid in
a path for the most part. When it coems to the filesystem along with the
@ stuff I can use percent encoding also. Then this way regardless of the OS
the files on the disk can be named according to their names and such. However
if a system does not support a given character then it would fail to be
created however.