assets/developer-notes/stephanie-gawroriski/2017/12/08.mkd

   1 # 2017/12/08
   2
   3 ## 00:45
   4
   5 Okay so the pipe based communication between the system task and client tasks
   6 will be done by a new class I created: `PacketStream`. That class will just
   7 have a common implementation. The first use would be it being used by the
   8 Java SE host to communicate to sub-processes. Then later on when user-space
   9 stuff comes along, it will be used for that communication as needed.
  10
  11 ## 08:07
  12
  13 I am definitely going to need a security context and such. Basically within
  14 the system when tasks are performed everything will need to be checked against
  15 the task that is performing the action's security levels. This also needs to
  16 be integrated into the task and suite handling systems too. So there will have
  17 to be some kind of generic handling with the base system classes. Clients
  18 could potentially lie by using another client's security context but I will
  19 make it where obtaining security contexts is not possible (unless someone
  20 finds an exploit for that). The `SecurityManager` will then use the context to
  21 handle permissions and such.
  22
  23 ## 08:53
  24
  25 Okay so, maybe what I need instead of `SecurityContext` is an object which
  26 knows all the details of the current chore. Basically there will need to be a
  27 `Chore` which can represent the current chore an any of its details. Basically
  28 an object which can represent any running chore on the system. It would also
  29 need to include a means of referring to other chores and potentially
  30 performing actions on them as such. Each chore would also need the security
  31 system in place and a means to check security flags. There would basically be
  32 the following instances:
  33
  34  * The current chore.
  35    * This is always valid and always just represents the current chore.
  36  * Other chores.
  37    * On the system it will represent actual process data and managing them,
  38      like normal operating system tasks.
  39    * On the client, these will just be very shallow and just forward over the
  40      internal communication stream.
  41
  42 ## 09:32
  43
  44 I believe I understand the "client" permission. Basically for the means of
  45 permissions. These clients act as a group. Every application is always
  46 assigned to a single client, but libraries can be assigned to multiple clients
  47 as needed. It personally is a bit confusing the terminology. But I will say
  48 that it is for permission handling. So depending on the permissions, there
  49 are two sets: chores which can access only other chores in the same group, or
  50 chores which can access any other group (except the system).
  51
  52 ## 11:52
  53
  54 Okay there is an issue. `Program`s and `Suite`s are a bit different. Programs
  55 are just a bunch of classes clumped together, sort of. Actually, they are
  56 pretty much the same, except that Suites themselves represent programs and all
  57 of their classes in a single classpath. So currently `Program`s are just
  58 single archives. This needs to be changed where they are a one to one mapping
  59 with Suites. This means that for launching, dependency handling will have to
  60 be in the core CLDC libraries. The dependency system can be quite complex also
  61 so there is that too. Dependency handling also needs to be recursive too. So
  62 since this stuff will have to be in the CLDC code it will need to be very
  63 light. However this would then include all of the auxiliary classes which are
  64 currently sitting in `meep-midlet`. At least to the native system, when it is
  65 told to launch the specified program it will know which libraries should be
  66 included. But I will have a means to get the programs that it depends upon.
  67
  68 ## 12:46
  69
  70 But `Suite` itself can refer to multiple programs. So really apart from the
  71 system suite it really does not matter. So for the most part, things are
  72 handled exactly as to how they are, single archives with multiple potential
  73 entry points. So basically what I can do is handle dependencies at
  74 installation time and hardcode them sort of in a way. It would be rather
  75 fixed but it would be simpler. Although there still has to be dependency
  76 handling and such.
  77
  78 ## 22:52
  79
  80 Okay, so I have the same problem with contexts. Basically all system calls
  81 will need to be called with a context so that they work properly. I
  82 essentially need to write an actual kernel in the CLDC libraries to handle
  83 these things. There would be the actual kernel code itself but then there
  84 would need to be a specially initialized API bridge that is magically
  85 initialized and such. So ther would be some native internal kernel
  86 implementations, then those can be exposed by user-space calls. So this will
  87 end up like an actual operating system and such.
  88
  89 ## 23:34
  90
  91 The stream which connects the client with the kernel will need a quickly
  92 accessed flag which determines if the operation was a success or not.
  93 Basically a synchronous return value. So basically there will need to be
  94 a response system for it to operate correctly, but it still can be
  95 asynchronous for the most part. Just the client's data stream to the kernel
  96 will need to handle that case such as providing responses along with commands
  97 and such.