The basic idea is to support as much of the underlying architecture as possible, and allow low-level access to it; but offer our own, standardize interface, implemented on top of it.
Just interface the system with the usual POSIX file mechanisms, so we can deal with I/O terminals. Access can be done through a low-level object, but several views of files as more sympathetic abstractions (arrays, list, sequence, input or output channels, etc.) are needed.
To allow multithreaded I/O, we'll have to use select.
We should support dynamic loading of modules, and if possible modules in shared memory. We should also support (as far as possible) importing of standard low-level system modules. Have a look at how ELF works under Linux.
We shall port our usual TUNES thread system to POSIX, and use SIGVTALRM to time-schedule our cooperative threads.
See this forum and resource site.
This is a very useful package, and not only to TUNES: once it's done, we automatically obtain the capability to dynamically combine and recombine inputs and outputs of pty's:
This is much better than what, say, screen does, because we can independently remap input and output, and combine them in infinitely many useful ways. Because we can control pty's, we can fully control Unix programs, and allow these programs to interface TUNES nicely. With this, we can automatically have powerful text window systems and subsystems under Unix.
Of course, all that depends on there being some reliable pty daemon; until TUNES is very stable, a particular session can be dedicated to that (as TUNES is fine grained, there's no memory problem); most probably, separate from others (communicating by messages as usual).
Information: man tty, man pty, man select, more /usr/include/**/*.h, read emacs info pages, etc.
Reuse some existing X toolkit package and interface it to TUNES.
Candidates: Tk, GTk.
More generally than the above SIGVTALRM, we should support provide a standard TUNES interface to signals.
All the fork, popen, etc. primitives, should be available too, in a straightforward way. Processes are viewed as multiple TUNES "hosts" in a distributed system; as of performance, it should be made clear that forking won't increase the total machine speed (though it may increase the share we have!), so there is no reason to migrate on the same machine unless it eases communication. Merging servers into a one active and another one asleep may be good, unless there are security or time-share competition reasons.
Provide network communication via sockets. Apart from their low security/efficiency performances, they are the same as any other TUNES communication subsystem.