[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal: a standard local editing protocol
A few comments inside..
(Note I did not write my reply in a top down or bottem up manner, just as
needed)
On Wed, 4 Mar 1998, Dave Kormann wrote:
> (this is just a trial balloon. the mcp- prefix here is a placeholder
> pending resolution of the question in my previous message. the form
> is incredibly rough and needs rewriting for grammar, clarity, and so
> on. places where i've elided important stuff are indicated by text in
> square brackets.)
>
> The MCP local editing package, version 1.0
> The mcp-edit package is designed to facilitate client-side editing of
> text stored on a MUD server. It provides a mechanism to transfer a
> block of text to the client, which may then return the (possibly
> modified) text to the server. The protocol consists of two messages:
> mcp-edit-send and mcp-edit-reply
You probley need more..
>
> [ say something here about locking? should we provide a locking
> mechanism? if not, we should say so. ]
We should supply hooks for locking and perhaps even make it part of the
spec, but I'm not sure that it should be required..
>
> [ also, maybe we add a third message, s->c, mcp-edit-update, which
> requests some kind of update on the text stored at the client? ]
That gets nasty, because you really don't want to undo what the client has
been working on for 3 hours because someone added one line of code..
Perhaps a alert that it has changed and a way to request the changed text?
>
> in the following discussion, "server" should be taken to mean the
> implementation sending the 'mcp-edit-send' message, and "client" to
> mean the implementation sending the 'mcp-edit-reply' message.
I'd like to see reply replaced with something like upload..
>
> mcp-edit-send(type, ident, name, text*)
> Send a block of text to be edited. The behavior of a client on
> receipt of this message depends on the value of the TYPE argument and
> the particular implementation. In most cases, however, a client is
> expected to either present an interface to the user, permitting the
> user to make modifications to the text, or to do some local, automatic
> processing on the text. When this editing is completed, the client
> should return the edited text to the server with an mcp-edit-reply
> message.
>
> TYPE: A string matching the syntax of an MCP identifier which
> classifies the block of text; implementations are encouraged
> to provide editors tailored to a variety of text types.
> Defined, reserved type names include:
> moo-code: a block of code in the MOO programming language
> moo-object-description: a block of text providing the
> description for a moo object
> [come up with some more of these]
> [reserve a big chunk of namespace here]
> Implementations may make use of any type not explicitly
> reserved by this specification. Clients are not required to
> provide any special-purpose editors, but must provide a
> default general-purpose editor which accepts any type not
> having a special-purpose editor. Clients are required to
> this type unaltered; it will be required for the
> mcp-edit-reply message.
> IDENT: A string, possibly quoted, which uniquely identifies this
> block of text to the server. Clients are required to preserve
> this identifier unaltered; it will be required for the
> mcp-edit-reply message.
> NAME: a human-readable name for the text being edited. This
> argument may be used as, for example, a window title by the
> client. This argument is optional; if it is not provided and
> a human-readable name is required by the client, the client
> may construct such a name based on the TYPE and IDENT
> arguments.
> TEXT*: a multiline argument containing the text to be edited.
Looks good..
>
> mcp-edit-reply(type, ident, text*)
> Send an edited block of text to the server. The behavior of the
> server on receipt of this text depends on the value of the TYPE and
> IDENT arguments and the particular implementation.
> [ yadda, yadda, yadda ]
>
> TYPE: Defined as above. Clients should send a type: argument
> identical to the one received in a preceding mcp-edit-send
> message.
> [ define server behaviors for the defined types above ]
> IDENT: Defined as above. Clients should send a ident: argument
> idnentical to the one received in a preceding mcp-edit-send
> message.
> TEXT*: a multiline argument containing the edited text.
I do see a problem here, for some things you /will/ need a way to resend
text which is being edited (MOO code is a big one), so the name needs some
adjesting and you also need a way to delete a key from the list of keys
kept in the cases where your using a randomly generated string for ID..
>
> Example: an interaction between a MOO server and a client supporting
> the moo-code type.
>
> s -> c
> #$#mcp-edit-send type: moo-code ident: "#6924:bonk" name: "moo code: hello"
> _data-tag: 12f4b text*: ""
> #$#* 12f4b text: "THE ONE TRUE AND HOLY BONK";
> #$#* 12f4b text: "beware blasphemous imatations";
> #$#* 12f4b text: $you:say_action("%N %<bonks> %d. %D %<d:says>, \"OIF!\"");
> #$#: 12f4b
>
> At this point, the client presents a window with the code above to be
> edited. The window could be as simple as an external invocation of vi
> with the above lines or as complex as a language-sensitive editor with
> support for the MOO programming language. When the user signals to
> the editor to do so, the client sends the following message back to
> the server:
>
> #$#mcp-edit-reply type: moo-code ident: "#6924:bonk" _data-tag: 736f text*: ""
> #$#* 736f text: "THE ONE TRUE AND HOLY BONK";
> #$#* 736f text: "beware blasphemous imatations";
> #$#* 736f $command_utils:object_match_failed(dobj =
> player:my_match_object(dobjstr), dobjstr) ? 0 |
> $you:say_action("%N %<bonks> %d. %D %<d:says>, \"" + ((msg =
> $code_utils:verb_or_property(dobj, "bonked_msg")) ?
> $string_utils:pronoun_quote($string_utils:pronoun_sub(msg)) |
> "OIF!") + "\"");
> #$#: 736f
>
> ... and the server attempts to set the code of #6924:bonk() to the
> value of text:.
You might also wish to allow a way for the server to give a responce to
the upload, for cases where there is a error..
Zephaniah E, Hull.