MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: MCP experience story

> > #$# edit name: test.text upload: @set-note-text #388.text
> [snip]
> 
> This is a Lambdacore-style edit request. It's a separate protocol from 
> mcp, but looks quite similar.
> 
> It might be good to support both, changing back and forth for individual 
> users with an option.  In fact I'm going to recommend (if not implement) 
> this change on JHM and hence in the next JHCore.

I believe JHM and JHCore do support both edit protocols.  The problem is,
you have to know how to get the right one....  I haven't checked for sure
on JHCore, but on JHM, `@edit-option +local' means that you want to use
local editing, and `@client-option +edit' means that your client can handle
MCP local editing.  So +local but !edit means to use the LambdaCore editing
protocol.

> > This additional blank was very disturbing so I threw that stuff out. I dont
> > think that violates the mcp-spec. Actually the #$# should be at the
> > beginning of the line I think. Perhaps the only reason for that was to make
> > it a little harder for wizzes to send fake mcp commands to a colleague?
> 
> Well, the reason is so that people couldn't do things like use @paste to 
> spawn an edit session on everybody's client and annoy people, so people 
> couldn't embed mcp commands in moomail, page-echo messages, etc etc.  I'd 
> put it back in if I were you.

Right, to reiterate:  The reason was to make it harder for _just anyone_ to
send fake MCP commands to other people.  If :notify doesn't filter out #$#
lines, then any random can make your client do weird things.  Now, it's
possible that "authentication keys" should protect you from that; but it's
not certain, and the status quo is that they don't.

For the most part, MCP messages can go through player:client_notify (in
JHCore; LambdaCore has no attempt at MCP support).  :client_notify uses
raw notify().  (Another reason for this is that, if you happened to have
@wrap on and MCP messages went through :notify, :notify would chop them
up into 75-character lines.)

> > In #6:maybe_really_disconnected there is a fork statement that transfers a
> > player home after a certain amount of time. There I put in a line that
> > resets the edit-option:
> 
> This is actually a fairly good idea if the client you use automatically 
> sets the option.  A more realistic option for moos with other clients 
> would be to leave the edit-option as it is and have some per-session 
> override that could be done by the client.

What I really think should happen is this:

  * "option" (what the user prefers to do) should be separated from
    "capability" (what the user's client _can_ do).
    o in this case, the option is "(use/don't use) local editing", and
      the capability is "MCP-style, LambdaCore-style, or none".
  * a simple heuristic should be used when invoking an editor:
    o if the user doesn't want local editing, it shouldn't be used (duh).
    o if the user wants local editing but eir client doesn't support it,
      it shouldn't be used (duh).
    o if the user wants local editing and eir client supports one or more
      protocols, pick a protocol and use it.
  * clients that support a local editing protocol should tell the server
    that as early in the session as possible.  (the "#$#mcp version: 1.0"
    line is intended to let the client know when that is.)  until and unless
    this information is sent by the client, the server should assume no
    local editing capability.

This means that the server should remember the _option_ from session to
session (since the user's preference isn't expected to change, and if it
does, it should be changed explicitly).  It also means the server should
_forget immediately_ about the _capability_ when the user disconnects.
(If the user connects again and the client doesn't send a capability
message, the correct deduction is that the client doesn't support local
editing.)

The reason this doesn't happen now is that LambdaCore-local-editing
clients don't send a capability message, so we ended up using the persistent
setting (@edit-option local) to indicate it (sort of), on the assumption that
most users use the same client most of the time.  But this fails sometimes,
and can be a pain for people like me (architects of this mess), let alone
people who just found the software and are trying to use it.

Note that once Jupiter comes out, we'll have a new set of issues relating
to integration of different protocols with one another.  On the other hand,
if you're in a position to make all your users use Jupiter clients, the
local-editing issue becomes moot.
References:
Home | Subject Index | Thread Index