[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proposal: a standard local editing protocol
(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
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
[ say something here about locking? should we provide a locking
mechanism? if not, we should say so. ]
[ 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? ]
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.
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
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
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
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
TEXT*: a multiline argument containing the text to be edited.
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
[ 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
TEXT*: a multiline argument containing the edited text.
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!\"");
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
#$#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")) ?
"OIF!") + "\"");
... and the server attempts to set the code of #6924:bonk() to the
value of text:.