[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>Shouldn't it be:
>#$#edit* 12345678 type: text name: Dave.test upload: "@set-note-text #75.test"
>#$#@@@This is a test.
Not according to the spec.
>Otherwise how will the MCP parser catch the @@@... lines?
In a MOO implementation, there are least three ways to do it, with
varying pros and cons: A @@@* verb on $room or $player, a hook in
#0:do_command(), or a simple read() loop. For other implementations,
you're on your own.
>Should it listen to the in-band lines until it get #$#END ?
Yeah, that's how the spec goes. At least, until it gets #$#END or a
non-conforming line, which is a sign that something went wrong (like a
traceback or a suspend).
Look, this is clearly a hopeless mess. But that's a big part of the
reason we started on MCP 2.X in the first place, which I like to think
of as "a less hopeless mess". See, one way of fixing problems with
MCP 1.0 is to make it obsolete.
FWIW, as far as I know there are no extant MCP 1.0 applications that
use client-to-server multiline messages. So the only reason that you
would need to implement this is if you are designing _new_ protocols
for use with MCP 1.0. It is my fervent hope that no one will ever do
this again. If you want to support existing MCP 1.0 applications
(most significantly JHCore local editing, I suspect), go ahead, but,
like, don't worry too much about conformance to the 1.0 spec.