Reflective architecture

[Tril]

OK, folks, this is my latest attempt to define reflection, so get your
flamethrowers warmed up........err, I mean constructive criticism.

==============================
By definition, a kernel is static.  But everything should be able to be
changed.  So nothing should be in the kernel-static. 

By definition, a kernel is more trusted.  But all code should be trusted. 
So everything should be in the kernel-trusted. 

By definition, a kernel is more optimized, because it is used more often. 
The reason it is used more often, is because it forces everything to go
through it to do anything.  But different users have different uses, so
what the designers put in the kernel may not be what every user does more
often.  What the user actually does more often, is what should be more
optimized.  So the system should observe what the user does often, and
optimize that.  So what is in the kernel-optimized should change based on
the user's changing activities. 

By definition, a kernel is a central module through which all information
passes.  But centralization is inefficient.  So the flow of information
should be adjusted to flow where it is needed.  So the kernel-central is
broken into many smaller nonkernel-decentrals. 

In fact, for a given system, we should start with the boundaries between
objects (abstractions), including their nested structure, being chosen for
easy understanding by the user.  This initial topology is also convenient
because it is completely platform- independent.  Initially set each object
as a decentral node of information flow, all with equal priority.  Then
begin observing where information flows.  The paths that are frequently
travelled by information can be combined, and abstracted:  effectively
creating a completely different set of objects.  These are system-objects,
and they are a result of: the user-objects which serve as the
specification for the tools in the system; the user's habits and
preferences, which impact the ways in which tools are used, and the flow
of information between them; and the hardware platform.  If any of these
aspects change, the system-objects should be changed to adapt. 

User-objects are the medium by which the user to controls and communicates
with the system.  User-objects are easier to understand than
system-objects, because user-objects are specifically designed around the
way humans think.  System-objects are much harder to understand, but their
structure corresponds with the way people think.  Also, user-objects
contain more information, because some information is lost during
translation to machine architectures.  Each time the system regenerates
the system-objects, different parts of the user-objects may be used. 

We call such a system reflective, because the system-objects reflect the
user-objects.  A kernel architecture (and other architectures) presumes a
particular information flow among objects.  In a reflective system,
nothing about topology is presumed, so the maximum freedom in architecture
can be achieved. 

The actual reflection process, or creating system-objects from
user-objects, need not be solely a manual nor automatic process.  Ideally,
the user and system cooperate in the process, because the system cannot
consider as many possibilities or come up with new approaches, and the
user cannot continuously repeat trivial actions. 

The user can, to understand how the system works, observe the
system-objects corresponding to his/her user-objects and adjust them to
experiment with efficiency and to help the system achieve abstractions
that better suit it.  Hopefully the user will then be able to automate the
adjustments just made, so others can benefit. 


David Manifold <dem@tunes.org>
Copyright 1998 David E. Manifold
Do not redistribute outside the tunes mailing list without permission.