[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: FromNess, ToNess
- To: <joel>
- Subject: Re: FromNess, ToNess
- From: Roger Gregory <roger>
- Date: Tue, 6 Feb 90 12:55:18 PST
- Cc: <xanatech>
We need to allow the system to be very flexible so developers
can create applications according to their requirements. This will most
likely mean creating their own document/object types. As Marc points out,
we can't assume to know the many different kinds and implementations of
document objects developes will want.
But it would be a big mistake to give all this power to developers without showing
them how to use it. This is what the conventional 4 link types and the document level
are for. When our developers first get this software they will not have the slightest
idea of what to do. I would expect most developers would invent document types with
the same wild abandon as early mac users used fonts. This would be a disservice to
them as well as to our software.
It is very important that fe's are able to read each others documents, both for
the public system and for office uses. We know a lot about how this stuff will be used,
at least I do, but we will have to feel our way carefuly into new document type creation,
trying to maintain sanity and compatibility. This was one of Ted's central ideas
in the initial invention of the system and it holds as much now as it dit then.
Remember most people aren't langauge & system designers, most developers aren't either.
While we need to provide the capability use the felexibility of the system, we should
strive to remove the necessity to push the limits of the designed and tested
document types. This means we should be out on the edge of design space first, because
we have some idea of what to expect and avoid. Since that sounds likely anyway, knowing
us, I suggest we be very careful with allowing users to create new documents types in the
beginning. Perhaps the first 5 or so new document types that users want should be
implemented by us, just so we get a feel for what the problems are, both with the code
and with the user design&specifications. Then we can free things up to relieve us of
the work involved.
In another message Joel asks about object servers. I thought we had dealt with
that last year. Aside from the relative advantage arguments advanced then, i.e.
existing object-servers sell speed and optimization, which we won't have in their
area of competence, they are cover a special purpose nerd-market, while we will sell to
those who read or write (or listen&talk or draw&look at pictures).