The TUNES Subproject Tree

To know more about subprojects, see the TUNES Charter.

The Tree

Actually, subprojects can be ordered in any way, not only tree-wise; but a tree is the easiest way to express the dependencies between subprojects.

Goal: Review all existing computing systems and computing system elements, and determine what is good or bad about them, what they lack, and what they do that they shouldn't, so that the TUNES project may benefit from their experience.
Maintainer: Ultima

Goal: Design and implement a high-level language that would fulfill all expressiveness, reflection, dynamic extensibility and restrainability, logical specifiability requirements for the Tunes project (as no available one seems to do).
Maintainer: Far�

Goal: Its goal is to design and implement generic tools to integrate the Tunes HLL with objects (in source or binary form) from other universes, or other contexts in the Tunes HLL.
Maintainer: Far� and Brian Rice

Goal: Design and implement tools to transform programs written in C into well-behaved programs in the Tunes HLL, with program-dependent customizable context. Instances would allow (semi) automatic translation of C source for Unix (or even device drivers from, say, VSTa or Linux) into HLL modules.
Maintainer: Far�

Goal: Its goal is to provide a frame where all common algorithms and data structures are to be written once and for all, instead of requiring everyone to reinvent incompatible wheels, and redundantly load the overall network traffic with these copies.
Note: This implies automatic world-wide unique identification of objects, and constitution of institutions to promote some objects as "standard".
Maintainer: Brian Rice and Far�

Goal: Define a core subset of the HLL that be easier to implement for bootstrap purposes, yet allow for further self-extension into the full HLL.
Maintainer: Far�

Goal: Develop generic and specific interfaces between the humans and the computer objects, at all level, be it immediate interaction or programming style, syntax, etc, so as to provide the greatest freedom to all users. It should be nicely integrated into the Tunes HLL.
Maintainer: Brian Rice and Far�

Goal: Develop study and implement the concept of dynamic object migration (including duplication) in a fine-grained distributed computing system.
Note: It should provide a way to allow objects to dynamically fill the available computer resources, while respecting the human-defined constraints to please users: economize computer resources (including time spent), still communicating to the human user wherever they are, etc. All the migration scheduling should be under full user control, be it direct, indirect, remote, or purely potential.
Note: Actually, Migration encompasses Garbage Collecting, Swapping, Remote Procedure Call, Publishing management, and more.
Maintainer: Far�

Goal: Its goal is to design and implement a portable low-level language and object encoding format, that would allow dynamic object migration.
Maintainer: Far�

("On Top Of POSIX")

Goal: Write some architecture-independent code so that Tunes would run on top of any POSIX-ly compliant enough system (i.e. a workstation running some recent Unix clone).
Note: Portability, not efficiency, will be the primary goal. Thus the code should be modular enough so that the implementation ported to other platforms and parts could be replaced by architecture-specific code.
Maintainer: Far�

Goal: Its goal is to implement the architecture-dependent code so that Tunes would run on any intel-based PC compatible computer with a 32 bit processor.
Maintainer: Far�

Annotate this on the CLiki.