Medusa As A Style Concept

[Eric Dean Tribble <tribble>]

I'm actually rather surprised at the lack of responses to this
message.  Some the shots were pretty cheap, so consider yourself
punished :-)  

The evolutionary model creates a conceptual spectrum between
supporting diversity and supporting selection.  In fact, we intend our
tools to support both generation (diversity) and selection
(filtering).  The distinction you want is really the distinction
between mechanism and policy.

While building a foundational mechanism, we quite properly avoid
embedding a particular policy into it.  This overwhelming focus on
*avoiding* implementing policies has bled into the other layers of the
system.  The D&L layer defines a layer of *policy* on top of the very
general backend.  By clarifying when we intentionally descend into
deciding or suggesting policy, we can hopefully avoid our heuristic to
avoid it.

In particular, let me note that no policy is ever *stupid*.  For
instance, any given set of link types will support some kinds of
communication and discourage other types.  We can separate the
evaluation of a proposal into what does it support/discourage, and do
we want to support/discourage those kinds of communication.  The first
is a matter of evaluation.  The second is a matter of opinion, and the
only place I can imagine stupidity.  I consider discouraging
refutations to be stupid, for example - any arguments? :-)  

For link types, we should examine the issue of what kinds of
communication do we want to support/discourage.  Note that equally
supporting all "communication" just increases bandwidth without
improving our ability to deal with it.  Our ability to filter will
allow users to selectively filter the increased bandwidth.  Great!
What do I filter for?  We have great generic answers, but few specific
ones, and specific ones will probably sell better.

Now plug any other interesting policy issue into the above vague
discussion.  

- Any discussion of policy (suggested patterns of use) will benefit
from being flagged as such.

- We probably need to have a policy to go along with EVERY general
mechanism that we provide.  This will orient our users and developers.
There's nothing stopping us from coming up with more than one pattern
of use for a given machanism (work types, lin types, coordinate space,
etc).  This will suggest generalizations to developers.

Finally, since we spend so little time on desinging policies, we
should carefully keep the selection pressure down to a level
appropriate to the variation rate.  We had a similar problem when
first spinning up with technical ideas.  As a background task, the
support of another alternative is far more useful than the burden of
another constaint.

whew.
dean

PS.  Note that people buy policy: I use a spread-sheet, not a
constraint solver.