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