feat(kernel): Implement typed messages for primary kernel components #80
Description
(Adapted from @FUDCo)
We should break out the type definitions for the various messages for the various message protocols of the different components so that they’re not all lumped together in one type def. Each of the components has a set of messages that can be sent to it, and we should be keeping these distinct (though this is muddied somewhat by the fact that, at least at the moment) some messages are handled by forwarding them to another component rather than processing them directly. One issue this raises is the proper scope of the type declarations. The easiest thing may be to just put them all in messages.ts. This tugs against various strict modularity principles, but the set of all the interacting components we’ll be dealing with and the messages they’ll exchange is small and finite (and likely to remain that way), so this may be fine until we decide on something more rigorous. With respect to messaging, we should have four components that we need to conjure with w.r.t message interactions:
(A) cluster service worker
(B) cluster offscreen page
(C) kernel worker
(D) vat iframe
(verbose labels chosen for clarity, and of course c.f. all the previous discussion about the proper naming of the components themselves). So we end up with something like the following message types:
ClusterCommand(A->B)ClusterCommandReply(B->A)KernelCommand(B->C)KernelCommandReply(C->B)ClusterSyscall(C->B)ClusterSyscallReply(B->C)VatCommand(C->D)VatCommandReply(D->C)KernelSyscall(D->C)KernelSyscallReply(C->D)
It might be nice to have some way to fold the various reply types in with the message types they are the replies to.