assets/developer-notes/stephanie-gawroriski/2016/10/12.mkd

   1 # 2016/10/12
   2
   3 ## 08:05
   4
   5 One thing I can actually do with the display server is to implement it with
   6 the GCF classes. I could basically use it as inter-midlet communication for
   7 the most part essentially. However because the server socket cannot be
   8 unblocked (should have used `InterruptedException` or a timeout), once a
   9 connection to made to the display server it work create a new thread that
  10 runs the display sockets connection. If the socket disconnects then the
  11 display instance would be destroyed. Then this way, I do not need to have it
  12 where the display code uses internal socket code, that would be hidden
  13 away in GCF. This would allow me to change it if it turns out rather nasty.
  14
  15 ## 10:08
  16
  17 I suppose `Connector` will always use kernel sockets. Special protocol
  18 handling would be performed by the kernel code. So if it is IMC it will
  19 send the data to another process, otherwise it will create network
  20 sockets potentially, or perhaps even open serial ports.
  21
  22 ## 10:16
  23
  24 Ok, so I will need a new project which stores the socket options. It is
  25 a dependency for the `auto-interpreter` project and will be a co-depend
  26 of `cldc-compact`. This way duplicated of constants does not have to be
  27 done. The kernel sockets will operate in the given manner. There will
  28 basically just be a `socketOpen` which returns a socket descriptor.
  29 Each socket will have data input, data output, and configuration. The
  30 configuration would essentially be like an ioctl of sorts. There would
  31 also need to be properties. There would essentially be two streams of
  32 sort. However the non-data ones would be datagram based while the others
  33 would be stream based. However confiuration and properties is kind of
  34 bad naming. So I would instead have it be called "control". Since the
  35 kernel socket could would be very raw, essentially error values will
  36 have to be returned from the methods.
  37
  38 ## 10:26
  39
  40 The ordering would have to be in order. So essentially this is what the GCF
  41 code will do when it goes to open a socket.
  42
  43  * `int fd = SquirrelJME.socketOpen();`
  44  * ... any `ConnectionOptions` (using `socketConfigOut()`) ...
  45  * `SquirrelJME.socketControlOut(CONTROL_URI, __toUTF8(__uri));`
  46
  47 Once CONFIG_URI is passed, it will treat it as an open request to be
  48 performed. So then thinking about it there will have to also be an
  49 additional properties along with data and control. The properties would
  50 be used by the client to figure any extra stuff that may exist. So
  51 essentially it would be:
  52
  53  * `int SquirrelJME.socketProperty(PROPERTY_FOO, __out, __off, __len);`
  54
  55 There are only a fixed number of socket types, so there really would not
  56 be a large set of values.
  57
  58 ## 10:37
  59
  60 Although, all of this could potentially be done with just a single method,
  61 although two would be best for input and output. Basically it would be
  62 something such as:
  63
  64  * `int socketOut(int __d, int __c, long __t, byte[] __b, int __o, int __l);`
  65  * `int socketIn(int __d, int[] __c, long __t, byte[] __b, int __o, int __l);`
  66
  67 When a reader reads from `socketIn`, it could be a configuration setting
  68 or actual data. This means that the socket can have an enforced linear
  69 processing of data. So say if a read request was performed, if the
  70 implementation of the GCF classes while requesting data gets a non-data
  71 channel read, it will just handle the event as needed. The only thing
  72 would that I would need a special error which specifically states that a
  73 request size is too short. So for the control channels, there would need
  74 to be a return value such as `BUFFER_TOO_SMALL` for example. This would
  75 only happen for non-data connections however. Everything other than
  76 the data channel will be datagrams, while the data channel will be
  77 streamed. So this way it can operate in single bytes if it wanted to.
  78 The only thing I would need for the GCF implementations would be copied
  79 buffers because it is very possible for another thread to mess with the
  80 buffers if they are used for user input. So there would essentially be
  81 internal buffers for safety.
  82
  83 ## 10:46
  84
  85 I could also probably add sub-channel data perhaps too. Or actually
  86 instead have: DATA, CONNECT, CONTROL, PROPERTY, and everything above those
  87 would be socket dependent. I would reserve a range for these channels in
  88 the event I need to add more.
  89
  90 ## 12:08
  91
  92 I would have to make sure that the socket code handled by the kernel
  93 implementation of it is ordered.
  94
  95 ## 12:59
  96
  97 When I write a web browser, I believe I would allow any URI provided by
  98 GCF to be accessed. Although this could sort of be nice in a way. There
  99 would need to be special handling for `file` though so that it opens in
 100 only a read mode.
 101
 102 ## 13:04
 103
 104 Unless the read/write mode is really again just a hint. The only thing I know
 105 of where read/write makes sense would be files. Other than that, having
 106 other sockets you cannot write to when you need a read would be a bit
 107 pointless.
 108
 109 ## 15:42
 110
 111 Need a URI library for this.
 112
 113 ## 15:57
 114
 115 The IMC connection use colons to separate pieces of the host along with
 116 semi-colon. This means that MIDlets cannot have colons or semi-colons in
 117 their suite name.
 118
 119 ## 16:02
 120
 121 Actually, I am going to need a midlet identification system and launch setup
 122 classes. `project` will have to depend on it along with `launcher`. The
 123 classes can be used to verify that midlet details are correct for example.
 124 The version has to be checked, the name for illegal characters, and other
 125 such things. However, the code can be shared by the launcher and the builder
 126 so it can correctly parse and output.
 127
 128 ## 16:46
 129
 130 Also, the `auto-interpreter` could potentially share things such as basic
 131 kernel operation, so I should have a base class called `kernel` which manages
 132 such things.
 133
 134 ## 17:38
 135
 136 So now that I have the name, version, and vendor stuff I can have it so the
 137 project manager uses those instead.
 138
 139 ## 17:42
 140
 141 Oops, so the liblet is actually "Liblet-Name" and not "Liblet-Title", this is
 142 an easy fix.
 143
 144 ## 18:01
 145
 146 I believe the auto interpreter will have to build every project anyway because
 147 the launcher will want to read the namespace manifest for binaries (to detect
 148 liblets and such).
 149
 150 ## 18:05
 151
 152 So the launcher at start will go through all "raw" namespaces and build a
 153 mapping of liblets and midlets. Only midlets will be shown, since they have
 154 main entry points.
 155
 156 ## 18:20
 157
 158 I wonder how hashable the midlet name, vendor, and versions are.
 159
 160 ## 21:00
 161
 162 Thinking about it, IPC can be just datagrams since streams can be layered on
 163 top of them. They can just be ordered mailboxes for the most part. The only
 164 thing are replies and notifications.
 165
 166 ## 21:08
 167
 168 Mailboxes would likely be the most sane, since they are asynchronous and do
 169 not have much overhead. For some connection types, there would just have to
 170 be special messages of sorts. I suppose for security there would be a mail
 171 stream connection that the kernel uses. Before two processes (including the
 172 kernel) will allow letters to be passed through, they must agree to a mail
 173 route. Messages will be waiting in the other's mailbox in the order they
 174 were sent. The letters would be colored with a simple 32-bit field which
 175 specifies the letter type. This way the other end know what to do with it
 176 without having to look in the passed byte array. Since byte oriented data is
 177 more sane for most things, the length should be enough.