Proposed project restructuring
Mon, 16 Feb 1998 15:21:17 +0000 (GMT)
I propose the following reorganization (well, it's an overhaul) of the
Integration: The goal of the Integration subproject is to assimilate
existing computing systems by specifying them within the high-level
reflective framework of TUNES. Subprojects are: Platforms, Languages
(formerly Metatranslator), Interfaces, Protocols, File formats, File
systems. Platforms are system descriptions. Anything TUNES can translate
to, it can also emulate. Before bootstrapping, integration will work on
writing high level specifications for current systems. After
bootstrapping, integration will create Tunes modules for these systems.
Innovation: The goal of the Innovation subproject is to design new
technology or improvements of old technology to implement in TUNES. The
parts are: Distribution (formerly Migration), Interfaces (formerly
Interfaces), Protocols, Languages (formerly Interfaces:HLL Syntax),
Libraries (standard Tunes library). Before bootstrapping Innovation will
design theory for new systems to be written in Tunes. After bootstrapping
Innovation will experiment and build these new systems.
Metalanguage: The goal of the Metalanguage subproject is to complete the
specification for the Tunes Metalanguage (formerly HLL). After
bootstrapping the Metalanguage project will be responsible for overseeing
major revisions of the reflective framework to ensure that important
features are not lost.
Bootstrapping: The goal of the Bootstrapping subproject (formerly LLL) is
to implement the Tunes Metalanguage initially, so we can begin using it in
the integration and innovation subprojects. The bootstrapping project
will wait and watch the Metalanguage project until it is finished enough
to start figuring out how to bootstrap.
Documentation: The goal of the Documentation subproject will be to
publish info about Tunes. This includes publishing the web pages for the
other subprojects. Documentation will make sure people know about Tunes.
Coordination: The goal of the Coordination subproject will be to organize
work being done or planned to be done for Tunes. This involves creating
new subprojects, keeping track of members of each subproject.
The Coordination subproject is responsible for management and finance
(when necessary). Coordination will make sure Tunes does not fall apart
due to lack of effort and organization.
Administration: The goal of the Administration subproject is to maintain
or keep an eye on the computing systems used for the Tunes project;
including the mailing lists, web pages, user accounts, DNS, and FTP.
Administration will keep everything in good working order so that the
project does not fall apart due to technical failure.
Distribution: The goal of the Distribution subproject is to find a
distribution format for Tunes, find distribution centers, and make sure
everybody gets Tunes who wants it. Distribution might work as a
subproject (or a duty) of Administration.
If these changes get approved, I recommend we see how many volunteers
there are for each project, and create mailing lists as necessary to
service them. (Boot,Dist,Admin,Coord,Meta,Innovate,Assimilate,Doc?)
Once someone says this is OK I'll start volunteering. :-)
Unless otherwise specified all projects keep their associated subprojects.
Here are justifications for the changes proposed:
Migration: What you are really talking about is Distribution (as in
distributed computing). Migration is part of the system: it is the act of
moving an object from one context to another, which is an axiom. I think
we should call it Distribution, to avoid confusion.
HLL: The object system proposed is not truly a language, it is a set of
capabilities that describes all possible languages and methods of
inventing new ones. The HLL is a temporary abstraction that serves as the
basis for infinite successive abstraction systems (the system dynamically
evolving and improving as new models are found). I propose calling this
the Metalanguage subproject. Another reason for changing the name is that
Tunes is not "high level." Objects can describe concepts from high to
Interfaces: Isn't the "Syntax of the HLL" the same as making a text-based
interface for Tunes? Such a text-based interface would allow literate
manipulation of all HLL concepts (objects). It would require a lexical
display of objects as well as syntax for using metalanguage axioms.
I propose moving the Interfaces project to be a subproject of the
Review: Review should change its charter. No longer are we looking for a
language to use as a basis for Tunes; we are designing a new one (or have
we already designed it?). The assimilation aspects of Review can be moved
to the Integration project; while the comparative aspects can be spun off
to a web page separate from the Tunes project. I recommend recruiting for
Review from the entire net, regardless of Tunes, and setting up
independent mirrors for it as a resource to everyone, because Review has
the capability of being very popular and useful in itself. We can look
for other language/os comparison pages to ask to join with Review. It
should be able to survive without any members of the Tunes project in it.
David E. Manifold <email@example.com> http://www.pacificrim.net/~dem/
TUNES is a Useful, Not Expedient System (OS project: http://www.tunes.org)