Re: local editing

[Richard Godard <richard.godard@tecfa.unige.ch>]

>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?

Well is the problem just with mcp or with any editing scheme used in MOOs?
as far as I remember the MOO editors have that problem too, ditto for all
MOO editing commands...

>(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?

Yup, there is a lot of consistency/synchronization issues that can arise in
editing data in a multiuser db... unfortunately the MOOs core I am familiar
doesn't offer any facilities to prevent/avoid such errors

>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?

If you want that behavior, use the edit package through cords... though we
wouldn't like to see that behavior mandatory for the most basic
implementation of a local editing package. But it could be optional if both
the client and server support cords.

[Erik's approach of the editing]
>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.

Yup, cords would be the right way.

>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.

Well as I thought about the local editing my thought envolved along the
lines of what you described. Then I realized it was getting powerfull, big
and complicated and probably require a lot of core changes... so I thought
we would rather have all those functionalities as part of an object/data
browser/editor and keep the edit package straightforward and simple (even
if that make it error prone in some cases.)
If the edit package require too many core changes, I doubt it will spread a
lot and well that would be even more annoying than having a limited edit
package.
For MOO maintainer that are more adventurous and ready to hack their MOO a
bit, installing a more powerfull object editor/browser package would be an
option...

Richard