Okay so the pipe based communication between the system task and client tasks will be done by a new class I created: PacketStream. That class will just have a common implementation. The first use would be it being used by the Java SE host to communicate to sub-processes. Then later on when user-space stuff comes along, it will be used for that communication as needed.


I am definitely going to need a security context and such. Basically within the system when tasks are performed everything will need to be checked against the task that is performing the action's security levels. This also needs to be integrated into the task and suite handling systems too. So there will have to be some kind of generic handling with the base system classes. Clients could potentially lie by using another client's security context but I will make it where obtaining security contexts is not possible (unless someone finds an exploit for that). The SecurityManager will then use the context to handle permissions and such.


Okay so, maybe what I need instead of SecurityContext is an object which knows all the details of the current chore. Basically there will need to be a Chore which can represent the current chore an any of its details. Basically an object which can represent any running chore on the system. It would also need to include a means of referring to other chores and potentially performing actions on them as such. Each chore would also need the security system in place and a means to check security flags. There would basically be the following instances:


I believe I understand the "client" permission. Basically for the means of permissions. These clients act as a group. Every application is always assigned to a single client, but libraries can be assigned to multiple clients as needed. It personally is a bit confusing the terminology. But I will say that it is for permission handling. So depending on the permissions, there are two sets: chores which can access only other chores in the same group, or chores which can access any other group (except the system).


Okay there is an issue. Programs and Suites are a bit different. Programs are just a bunch of classes clumped together, sort of. Actually, they are pretty much the same, except that Suites themselves represent programs and all of their classes in a single classpath. So currently Programs are just single archives. This needs to be changed where they are a one to one mapping with Suites. This means that for launching, dependency handling will have to be in the core CLDC libraries. The dependency system can be quite complex also so there is that too. Dependency handling also needs to be recursive too. So since this stuff will have to be in the CLDC code it will need to be very light. However this would then include all of the auxiliary classes which are currently sitting in meep-midlet. At least to the native system, when it is told to launch the specified program it will know which libraries should be included. But I will have a means to get the programs that it depends upon.


But Suite itself can refer to multiple programs. So really apart from the system suite it really does not matter. So for the most part, things are handled exactly as to how they are, single archives with multiple potential entry points. So basically what I can do is handle dependencies at installation time and hardcode them sort of in a way. It would be rather fixed but it would be simpler. Although there still has to be dependency handling and such.


Okay, so I have the same problem with contexts. Basically all system calls will need to be called with a context so that they work properly. I essentially need to write an actual kernel in the CLDC libraries to handle these things. There would be the actual kernel code itself but then there would need to be a specially initialized API bridge that is magically initialized and such. So ther would be some native internal kernel implementations, then those can be exposed by user-space calls. So this will end up like an actual operating system and such.


The stream which connects the client with the kernel will need a quickly accessed flag which determines if the operation was a success or not. Basically a synchronous return value. So basically there will need to be a response system for it to operate correctly, but it still can be asynchronous for the most part. Just the client's data stream to the kernel will need to handle that case such as providing responses along with commands and such.