# MCP experience story

Erik Ostrom (eostrom@ccs.neu.edu)
Tue, 17 Oct 1995 13:46:33 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

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