local editing

[Erik Ostrom <eostrom@research.att.com>]

this seems like a fine place to talk about 'standard packages',
although i'd like us someday to, you know, have a protocol spec.

the approach to local editing taken by mcp 1.0, which is very similar
to the one you propose, has a number of problems dealing with
consistency: how do you make sure the "reference" always refers to the
same thing?  (some clients allow the user to change the "reference" in
an unstructured way, which is both really handy and the root of all
sorts of trouble.)  for example:

  #$#edit-content reference: "#1:name_for_look_self" content*: X _data-tag: 1

(imagine the content for yourself.)  now, what happens if
#1:name_for_look_self is deleted?  an error, probably.  what if it's
renamed?  maybe an error, but why should you lose in that way?  what
if it's renamed but another verb with the same name is installed?
should you be overwriting the new code?

along other lines, what if you want to have two editors open on the
same reference?  (for example, one window showing the original text of
the verb, another showing your current edits.)  when the server sends
a message regarding that reference, how does your client know which
window it belongs to?

these aren't contrived examples; they happen to me a lot.

i think the right way to approach local editing is to have the
fundamental object of operation be an "editing session", rather than a
"thing being edited".  an editing session has a number of operations:
it can be opened by the server or the client (and rejected, in either
case, for different reasons).  initial content can be sent from the
server; under certain conditions, the server can send updated
content.  a session has both a "reference", which is an oblique
identifier used to specify a _particular session_, and a "location", which
is a _human-readable_ description of what the session refers to.  the
location can be changed by the server (as when the verb's name is
changed); the client can request a location change, subject to
approval by the server (as when you want to copy the program code
you're using into a different verb).  of course, the client can
request to "save" its current text, again subject to approval.
finally, either client or server can close a given session.

the obvious design of an editing session is a cord.  it's also
possible to design editing sessions with a separate structure of IDs
and opens and closes, if you like wheel reinvention.

i realize this may be more than you thought you were bargaining for
when you brought the subject up, but my feeling is, if we're going to
reinvent local editing, let's do it better this time.

--erik