At 03:07 PM 7/12/2000 -0700, Daniel A. Koepke wrote:
>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.
One could argue that, given the sucess of recent MMORPGs such as
EverQuest, which, given their graphical nature (and commercial nature)
are limited to the one fixed interface. Something that works with text
but enhances it with easy shortcuts via mouse is desired. Or at least
I'm biased enough toward MXP to think so. :)
> * Human readable markup languages are ill-suited for multiple-user
> interaction.
How so? Especially since the markups are redefineable by sending
a few elements.
>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.
As strong as XML is, it really hasn't yet "caught on". Most people are
still hesitant to implement it because it's too new to rely upon. Who knows
if it will be abandoned in favor of something else? After all, Mozilla is a
project that most people consider to be dead, or close to death. Whether
or not this is actually true is another story.
>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.
I disagree, but I think this falls to a basic question of your belief in human
nature. I, perhaps optimistically, think that Zugg has two motivations:
1.) This is his job. To keep people coming, he must improve the client
both in stability (free upgrades win him points here) and in features. At
this time, zMUD is developed enough that there really cannot be a stronger
feature-set without MUDs growing another step to give him something
to support.
2.) His biggest adversaries at the moment, that are selling very very well
are the MUD Client / Monthly Service package deals for thinks like Diablo
2 and EverQuest.
>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.
Agreed. It's a standard communicated usually over the HTTP protocol. His choice
of wording is regretfully ignorant, I must conceed that.
:2s/HTML/HTTP/
:1,4s/Telnet/TCP\/IP/g
:3s/enhance/operate over/
Better? *grin*
>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
The fact that he is thinking about this ahead of time is a good thing. For the
most part, I think the worst exploit (given statements in the spec) would be
to turn around and send data back to the MUD as the user. Potentially
abuseable to delete the character. Something which could be done with
triggers as it stands already.
What worries me more is the possible cross between COM support under
zMUD with MXP. Other MUD clients supporting MXP would not need to
worry about this. I hope he intends to either prevent COM calls from MXP
or only allow certain COM functions.
This all said, these are my thoughts:
* MUDs as standing with text and ASCII art are going to loose favor to the
new graphical MMORPGs. Hell, I'd have a more developed MUD if I stopped
playing EverQuest as much as I do.
* To compete, we need more control over the client display. This could be
achieved via VT10x escape sequences, but I believe this to be an ugly task
to try to accomplish.
* We also need sound (via MSP currently, this is acheivable) to add
atomosphere.
* Images would be a long step in keeping interest in a non-3D system.
If there are issues with MXP, I'd like to see an alternate recommendation
which has the support of at least one of the major MUD clients out there.
Or let's try to convince Zugg to what his flaws are and how they can be
remedied.
--SR
--
StormeRider "Peace favor your code."
thelastsunrise.net 9000 (http://www.thelastsunrise.net)
windsofstorm.net 4008 (http://winds.windsofstorm.net)
+------------------------------------------------------------+
| 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