On Wed, 12 Jul 2000, Alex wrote:
> Oh... so a redesign of the Pueblo extensions then?
People have very little perspective on these things. A mud markup
language was discussed indepth a number of years ago on some newsgroup or
another. It was considerably more thorough than MXP (I remember
provisions for joystick input, etc.), but eventually died out after a lot
of talk. I can think of two prevailing reasons:
* Muds have not began to even scratch the surface of playability
possible within their existing framework. Players are always
looking for a better game, rather than a better interface.
* Human readable markup languages are ill-suited for multiple-user
interaction.
MXP doesn't escape these, and it fails on a few other points, as well.
One large, new failing is that MXP is not-quite-XML. XML is capable of
expressing everything MXP can, albeit in a different (better, IMHO)
syntax. The argument that XML is document-bound is incorrect: XML
fragments are in use in XML-conforming products, such as XMLterm
(http://xmlterm.com/), and could be used here. Given that XML has a much
wider support base, including pre-existing parsers (for use in other
MXP-supporting clients) and clients (Mozilla/Netscape 6.0), the
introduction of MXP as like-it-but-not-it is frustratingly short-sighted.
This design decision suggests (to me) both a lack of understanding about
XML and an intent to keep other clients behind zMUD. The latter seems to
be supported by the following from the MXP spec,
Of course, zMUD will . . . always provide the richest implementation
of the MXP specification.
Even without this, MXP is poorly designed on many fronts. Like MSP, it
commits the cardinal sin of being a secure-space protocol easily
representable in public-space. Welcome to the world of hanging Joe User's
Win9x machine using !!SOUND(\con\con), or its MXP equivalent. A lot of
these problems are rooted in fundamental misconceptions about Muds, the
Internet, and protocols thereof. The opening paragraph of the MXP spec
provides some insight,
MUD Servers communicate with MUD Clients via the Telnet Protocol.
While Telnet is the basis of most Internet protocols (FTP, HTML,
SMTP, etc), most of these protocols enhance Telnet with their own
higher-level protocol in order to provide more specific and
directed features.
Shouldn't someone positioning a new protocol have at least a basic
knowledge of related protocols? FTP, SMTP, and, indeed, most Muds, do not
use the telnet protocol. Telnet is a protocol layered atop TCP/IP, as are
FTP and SMTP. HTML is not even a protocol.
There's a number of other worrying things in the spec. Not the least of
which is,
MUD Server Implementation Note: Be very careful when sending Secure
lines from the MUD. Be absolutely sure that MUD players cannot
control the output of a secure line. If a MUD player is able to send
a secure MXP command, he will be able to cause great damage to other
MUD players using MXP.
MXP, by way of XML and HTML, is a human readable markup language. This is
great when we're designing documents, and less than ideal when we're
dealing with in-stream data coming from a potentially untrusted server.
A server being untrusted does not specifically require the server itself
to violate the trust of the client (either maliciously or by a failure to
conform). Instead, the presence of untrusted clients who can influence
the output of other users (as is the case in Muds) mandates that any
client treat the server as an untrusted entity.
The MXP specification does precisely the opposite. It relies upon the
server to be trustworthy. This is equivalent to trusting the server (both
to conform and to not generate malicious output), the server's trusted
entities (administrators, builders, areas, mobiles, items, mud scripts,
etc.), and the server's untrusted entities (players, bulliten board
messages written by players, etc.).
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT