if (c++ && x++)

[Mark S. Miller <mark>]

More detailed responses later.  What I find amazing about the
discussion so far is that I agree with essentially everything
everyone's been saying.  It seems there is a spectrum which we can
define by the following two extremes:

The Low Road:
The developer who wants to learn as little new as possible, and to
stick as much as possible with what he's already familiar with.  This
is not a negative portrayal, there are many good reasons for having
this attitude.  For example, he may already be working with a large
application which he wants to retrofit to use Xanadu.  For this
developer, we need to document the Febe protocol, and give a very
basic procedural C interface for engaging in this protocol.  I imagine
this interface consists essentially of the messages to the Transceiver
class.  (Actually C procedures that correspond to these messages).
The Febe protocol would be documented both as a textual protocol
(using normal bnf) and in terms of the proper sequence to invoke the
Transceiver procedures (sort of like the RenderMan spec).  Let's work
together on what such a system would look like in detail.

The High Road: 
The developer who is starting from scratch, and would rather spend
time learning than reinventing wheels.  For this developer, our tools
can be a great asset which can eliminate what would have been the
first *six months* of development time for an ambitious application.


It is plausible that trying to provide a large C library would be
counter-productive.  If the low road above charaterizes the typical
developer who prefers to stick with C, then large libraries from us
would be an unwanted distraction.  Of course, there will be important
cases between these two extremes, but which ones these will be I can't
predict.  I propose that we start out supporting these two extremes,
and wait for feedback from our developers to decide which intermediate
points to support.  Roger mentions frontend caching support as a
possible such intermediate point.  Note that intermediate points may
largely be supportable by providing 'extern "C"' interfaces to X++
library code.

Can we just support one of these roads?  I fear not.  As you point
out, there is great reason to support the low road.  However, even if
only a small fraction of our developers take the high road, it will be
by and large *these* developers that develop the really great novel
applications that make us a success.  And they'll also develop these
much earlier.  (not counting the retrofitters.  I'm comparing low vs
high road for new applications.)  Those who start from scratch will
have in front of them much of what we've just spent the last six
months doing.

"You take the low road, and I'll take the high road, and I'll get ta
frontend a'fore ya ..."