[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
FromNess, ToNess
- To: <mark>
- Subject: FromNess, ToNess
- From: Ravi Pandya <ravi>
- Date: Wed, 31 Jan 90 08:06:53 PST
- Cc: <bobp>, <xanatech>
- In-reply-to: <MarkS.Miller'smessageofTue>,22 PST <9001310342.AA19692@xanadu>
Summary: I think modest evolution of the current set of Waldos in
Docs&Links will eliminate the need to expose Berts&Orgls.
Date: Tue, 30 Jan 90 19:42:22 PST
From: mark (Mark S. Miller)
Date: Tue, 30 Jan 90 10:24:13 PST
From: bobp (Bob Perez)
I've been meaning to ask this for some time: what advantages are there
(both for us and for the developer community) in releasing B&O? Apart from
N-ended links, what features do we anticipate getting used?
One can think of the Berts & Orgls layer as attempting to provide low
level semi-direct access to the powers of the Ent in a way consistent
with secure asyncronous distributed multi-party use. The Docs & Links
layer makes a *LOT* of policy choices about particular ways we think
are useful to use that power. When Docs&Links are the only Febe
interface, our users are locked into those policy choices. With
Orgls&Berts exposed, they can do Docs&Links like systems of their own.
The Docs&Links part of Docs&Links makes policy choices, but the
Record-level waldo interface (which will be available as part of D&L)
provides almost all of the power of Orgls&Berts, and with some further
evolution I think it will provide essentially complete access to the
functionality of the ent. This has the advantage of providing this
power as an extension of the tools that our developers will be using,
rather than as a whole new level of tools they need to learn.
....
I still agree with all the above as a design philosophy (provide both
the most general low level *mechanism* you can, as well as a default
*policy* for its use); however, since Ravi took over Docs&Links, my
anxiety about its quality has disappeared.
Thanks! However, mine hasn't -- I think you transferred your anxiety
along with the responsibility.
John Walker has an ammusing story about experience with users of
AutoCad utilizing multiple layers in unexpected ways (which he might
relate if he sees this. John?). The story helps remind one to design
general degrees of freedom even if you can't forsee what they're
useful for. Note that this isn't the same as providing lots of
widgets whose utility is questionable.
The current D&L provides some special-purpose policy widgets -- Docs,
Links, LinkEnds, LinkEndSets, ... -- along with some general-purpose
policy-free widgets -- DirectRecords, MappedRecords, WaldoSets,
IDSets, .... The only reference the general ones make to the special
ones is in creating a LinkEnd on a piece of material, and its
structure is such that it doesn't need to be inside a document, or
structured into LinkEndSets and Links. A LinkEnd by itself provides
that ability to follow, and anything above that is optional policy.
--ravi