assets/developer-notes/stephanie-gawroriski/2016/06/23.mkd

   1 # 2016/06/23
   2
   3 ## 03:16
   4
   5 A rather large thunderstorm is closing in.
   6
   7 ## 03:59
   8
   9 A _very_ large thunderstorm.
  10
  11 ## 04:32
  12
  13 Taking yesterday's idea, I can have a module based Java virtual machine.
  14 Basically the virtual machine is initialized and it searches for modules in
  15 the class path. The modules can provide filesystem access and such for example.
  16 The modules could also provide execution environments also possibly.
  17
  18 ## 04:40
  19
  20 The JVM at its base can be abstract, where implementations could implement
  21 native CPU support and such. So for example process creation and memory
  22 management is not handled by the JVM at all but by the implementation.
  23
  24 ## 04:43
  25
  26 Then using the filesystem module, class units that use that filesystem
  27 interface can be used.
  28
  29 ## 04:46
  30
  31 The JVM would be given main arguments, setup the launcher, and then just
  32 provide an interface for things. So the `JVM` would be similar to the kernel
  33 except that it would be far simpler and more modular.
  34
  35 ## 05:06
  36
  37 So `JVM` and family will just be similar to the kernel, then I can move some
  38 of the `PVM` code over it. This way there are somewhat common interfaces used
  39 and duplicated code for native implementations would be completely rewritten
  40 from scratch.
  41
  42 ## 05:28
  43
  44 Heard what sounded like a gun shot and the power failed, that would likely be
  45 a transformer.
  46
  47 ## 09:28
  48
  49 I believe for the filesystem, regardless of the OS I will use the same
  50 structure. The `@` will be the root specifier, followed by the name of the
  51 root. The directory separator would be `/`. All filesystems that exist on the
  52 host along with virtual ones will exist under this scheme. This would simplify
  53 the very different file system handling across various systems. So for
  54 example on Linux the UNIX root would just `@root/` while on Windows `C:` would
  55 be called `@c/`. The roots would be case insensitive.
  56
  57 ## 09:36
  58
  59 Not sure about the modules, but it should work.
  60
  61 ## 09:59
  62
  63 Actually for the device I/O, I should use the device I/O interfaces and such.
  64 This way I do not invent my own.
  65
  66 ## 11:26
  67
  68 Thinking about it, I am definitely going to need the JVM to depend on the full
  69 CLDC. Well actually, not really. I just need a nice design of the upper layers
  70 that is not very complex. For example, there could be built-in JARs such as
  71 in the `class-path` package that are purely native, there could also be ones
  72 that exist on the disk somewhere. Processes running on the JVM would be
  73 standalone in that they cannot access each other, except through networking,
  74 IPC, and the filesystem for example.
  75
  76 ## 13:00
  77
  78 Ok, so I have decided that for now `JVM` will just have default provided class
  79 unit providers. However, another thing I have decided on is having a URI
  80 scheme when it comes to class units. Instead of being identified by a string
  81 they are identified by a URI. The scheme would be the name of the provider.
  82 So for example if the default provider is called `default` then `foo.jar`
  83 would be represented as `default:foo.jar`. When JARs are requested as such
  84 when they are needed for dependencies for example the `JVM` will search all
  85 registered providers if a namespace is not specified. So if `foo.jar` is in
  86 the _Class-Path_ attribute then it will search for `default:foo.jar`. However
  87 if `orange:foo.jar` was specified then it will look for a provider called
  88 `orange` and then attempt to get a class unit for `foo.jar`, which could fail.
  89 Using this scheme, it is possible to have special class units which can be
  90 used for standards and the names of liblets for example. So something such
  91 as `liblet:Name%20Of%20LIBlet` could be performed perhaps.
  92
  93 ## 13:07
  94
  95 However, doing that would be a bit complicated since when looking for a liblet
  96 of a given name it can be cached or have it where the manifests are searched.
  97 But, I must implement URIs since those would be very handy to have, and Java ME
  98 sadly lacks URIs.
  99
 100 ## 13:14
 101
 102 When it comes to URIs, I need to handle IPv6 and the inconsistent zoneID.
 103 However when it comes to parsing a string, if something is a IPv6 literal then
 104 it can sanitize the zone ID.
 105
 106 ## 18:03
 107
 108 Thinking about it, the test system could actually use URIs to refer to tests.
 109 Then I can pass arguments to tests and in general permit default tests to
 110 contain more information. Then I would also not need to have test specific
 111 areas be specific. So say that a test requires user input when it comes to
 112 validity, that can just be passed to say the query component for example.
 113 However before I can switch to URIs, I have to implement the URI test first.
 114 Once the URI testing is complete and URIs appear to work I can then switch
 115 the test system to use URIs instead. The URI could be in the form of say
 116 `test://package/test-name?anything-extra`.
 117
 118 ## 18:09
 119
 120 There could also actually be a standard query and argument set of things that
 121 is decoded for a requested test. So when a test is performed, the query and
 122 its fields will be read into a map of key/value pairs and passed along with
 123 the name of the test to perform.
 124
 125 ## 23:36
 126
 127 For paths in URIs, they should be fragmented and split into units and marked if
 128 a path is absolute rather than having a single group for paths. This would
 129 make resolution easier.
 130
 131 ## 23:40
 132
 133 Reading up on paths, they can be escaped which means any character is valid in
 134 a path for the most part. When it coems to the filesystem along with the
 135 `@` stuff I can use percent encoding also. Then this way regardless of the OS
 136 the files on the disk can be named according to their names and such. However
 137 if a system does not support a given character then it would fail to be
 138 created however.
 139
 140