<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Fw: DESIGN: XML? -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Sun, 02 Apr 2000 20:36:24 -0700 -->
<!--X-Message-Id: 00e101bf9d05$0ee5c600$020101df@JonLambert -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Fw: DESIGN: XML?</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00011.html">Previous</a>
| <a href="msg00013.html">Next</a>
]
Thread:
[ <a href="msg00013.html">Previous</a>
| <a href="msg00011.html">Next</a>
]
Index:
[ <A HREF="author.html#00012">Author</A>
| <A HREF="#00012">Date</A>
| <A HREF="thread.html#00012">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Fw: DESIGN: XML?</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: "Mud-Dev" <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] Fw: DESIGN: XML?</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Sun, 2 Apr 2000 20:38:57 -0400</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
I thought I'd forward this along too...
Most of it's old territory here but if I get it into the Mud-dev archives
I can get more experience points for it. ;-)
-----Original Message-----
>From: Jon A. Lambert <jlsysinc#nospam,ix.netcom.com>
>Newsgroups: rec.games.mud.admin,alt.mud.programming
>Date: Friday, March 31, 2000 3:09 AM
>Subject: Re: DESIGN: XML?
>
>David MacFarlane wrote in message <8br4sp$39p$1#newsmaster,pathcom.com>...
>>On Tue, 28 Mar 2000 01:00:58 -0500, Jon A. Lambert
>><jlsysinc#nospam,ix.netcom.com> wrote:
>>
>>>David MacFarlane wrote in message <8b8t0a$fbe$1#newsmaster,pathcom.com>...
>>>
>>>By catering to the lowest common denominator of user interface, your
>>>choices as implementor are limited by the users. Controlling the client
>>>gives the mud implementor complete and total control over presentation.
>>
>>It also gives them complete and total control over interaction and the
>>interface to the MUD, and it _will_ be in a way that some people don't like
>>(and hopefully, others do).
>
>Well there is certainly quite a bit of prior art and experience to
>point to (Zmud, Gmud, tk-MOO, Telnet, Mushclient, etc.).
>Obviously a well-written client is not going to ignore proven popular
>features and will be flexible enough to support an intelligent level
>of user customization. Some customization support will no longer
>be necessary since the server target is _known_.
>
>>There's also the manner of bugs and such that
>>your client will have and the client of said users choice might not.
>
>Given that user's client of choice simply won't understand the mud's
>output anyway it's a moot issue. Of course, I have to make a case
>for that. More below.
>
>>>Portability is no longer that big of a concern. Java, Delphi, and a number
>>>of other GUI frameworks are available across multiple platforms.
>>
>>Java is slow, and also requires a VM. Delphi, AFAIK, is only available on
>>a very small number of platforms.
>
>*sigh* No Java is not slow. It is more than capable for this application.
>Delphi now runs on Linux, Solaris and Win/NT. The key to client portability is
>in using existing frameworks (or failing that writing your own). Even if I was
>writing a generic client today, I'd be using a one of these frameworks (for example
>Andrew Wilson's tkMOO-light or maybe V).
>There are at least a dozen GUI frameworks and even more network
>frameworks to pick from. The client application code is pretty much just
>glue. If there are platform dependencies with using a given framework,
>I would maintain that it's a poor framework and wouldn't use it.
>
>> Native executables (most clients made by
>>other people) can be a lot faster but less portable. The portability however
>>is irrelevant since any platform will have a different telnet client. With only
>>the slightest amount of effort it shouldn't be too hard to get along with
>>each of them, since they're all designed to the same standards and most of
>>said standards are designed to not interfere with other clients that don't
>>support them.
>
>I'm not quite sure where you going with the native executable issue.
>Native code is much easier to distribute than source. In fact, I don't
>believe users are at all interested in compiling the client. I would
>certainly distribute native executables, unless I was using a frameworks
>or languages that didn't allow it.
>
>>
>>>Loads of interesting possibilities open up once you control the client.
>>>
>>
>>Most of which involve eye/earcandy and not the actual content of the game. (If
>>you can name some that don't, go ahead.)
>
>This is _all_ about content and context. In that regard, the poster who
>suggested XML is right. I happen to just disagree with the choice of XML
>as a network protocol. It is after all quite wordy. One school of thought is
>to implement new standards of client/server information exchange like
>Pueblo's HTML subset, CML, MSP, MCP, etc. and have client authors
>integrate these new protocols and their detection into new releases of generic
>clients, while at the same time supporting an unalderated telnet text stream.
>And then there's the custom client approach. Obviously it excludes those who
>insist upon the presence of an unalderated telnet text stream interface. I have
>absolutely no interest in those users. Nor do I have any interest in users using
>antiquated hardware (386s, 486s, dumb terminals) or oddball operating
>systems (DOS, OS/2, VMS). They just aren't worth my time or effort.
>
>Here are a couple of advantages of implementing custom client/server
>communication protocols.
>
>1) Client-side caching of information to reduce server bandwidth. This
> might include help files, room descriptions, graphics, sounds, etc.
>2) Client-side command checking, pre-parsing, spell checking, language
> translation.
>3) Peer client to client communications when appropriate to reduce
> server bandwidth. (i.e. Yahoo games, MS game network, Quake)
>4) Multiple port sessions to serve up supplemental information in
> the background. This may include any number of things like
> graphics, sound, client updates, a distributed server network.
>5) Automatic connection rerouting.
>6) Client side production of mapping information.
>7) Client side builder and programming interfaces. I'm a big believer in
> free user building and programming. YMMV.
>8) Clients that understand and display dwarven, elven, greek, alchemy
> symbols, mathematical symbols concurrently with one's chosen native
> character set.
>9) Client that understand formatting - font selection, pitch, centering, indenting,
> left and right justification, etc.
>10) Clients that have spamming governors, allow limited instancing (multiplaying),
> automatic registering and login to a peer network (i.e. ICQ).
>11) Clients that can understand and manipulate mud objects like an inventory,
> an equipment list, etc. Obviously within security tolerances.
>12) Client-side message/notes/bulletin board/mail editting and processing.
>13) Avatars. 3d mapping. Point and drool object manipulation. yada yada
>14) All users are equal. At least they all start on the same client playing
> field. If you don't allow triggers don't put them in the client. Obviously
> hacking the client, the protocol or shell automation are still options
> for your creative and determined user.
>15) On the flip-side if you like client robots and automation (I do),
> implement a form of customized scripting. One that understands
> context and available server-side functions. This is analogous to
> client-side player mobprogs (MPG).
>
>>
>>>I'm certain Zugg is a nice guy, but what the hell does he know about
>>>presenting my mud? ;-)
>>>
>>Well, considering zMUD is one of the most popular mud clients for Windows
>>and it also somehow manages to survive being shareware in a community of
>>mainly free MUDs, he must be doing something right.
>>All zMUD does is present what you, as creator of your MUD, tell it to.
>
>This isn't about the quality of zMud as a client. I think it's a fine client.
>I can't tell it to do anything of _value_ about the presentation. (see above).
>It knows absolutely nothing about context and the only formatting it
>understands are linefeeds and a few ansi color codes. Don't get me wrong.
>It does its job well, it's just not the job _I_ want to do.
>
>> The
>>only thing you lose control of is how the user interacts, not what they see.
>
>I lose control of what the user sees too.
>
>>Zugg may not know how to present your MUD, which is why you write all the
>>rooms/descriptions/so on, but likewise what do you know about how I want
>>to access your MUD?
>
>I don't care about you _specifically_, I do care about Mister or Miss Mostuser.
>Neither Asherons Call, Everquest, Ultima Online or Furcadia care about
>you _specifically_.
>
>I want YOU to view my presentation the way I intend it to be seen.
>It'll stand or fall on it's own.
>
>>>> They'd need to install your software which might not be
>>>>a possibility if they were using an obscure platform that you havn't ported
>>>>it to, or if they were somewhere that's restrictive about their computers
>>>>(say, work or school).
>>>
>>>So these people just can't or won't play. So what?
>>
>>So just that, they can't or won't. I don't know about you, but I like being
>>around a variety of people from different backgrounds and experiences. If
>>the only people who can play your mud are the (bleh) Windowsers, you've
>>narrowed down your potential userbase and where those users come from.
>
>Diversity and multi-culturalism based on platform. That's a new one. :-P
>Anyways the vast overwhelming majority of mud players are Windows users.
>While Linux users might form the majority of the posters and readers of this
>admin newsgroup, they are a distinct minority of the users who play muds.
>That said I'm interested in having my client run on both Windows and Linux.
>
>>>Write the client for the platform _most_ of your users will be using.
>>>If there's a big enough demand for another platform, port it, or
>>>get someone else do it.
>>>
>>
>>Assuming that most of your players will be from Windows, porting to almost
>>any other platform isn't so easy. The differences are big enough that you'd
>>probably be better off completely rewriting your client on the new platform,
>>which now doubles your work maintaining it. Now that you've got to maintain
>>a client on each platform that you plan on supporting you've shifted the
>>workload of fixing bugs in the client from someone else to you, along with
>>any bugs in the server.
>
>I think I already addressed this above with the use of frameworks which
>are in fairly wide usage and which have their own maintenance staff.
>I already use Delphi network and GUI components that exist on three
>platforms.
>
>>>>Not only that but it would be very inefficient.
>>>
>>>Inefficiency is writing and debugging hundreds of lines of code to handle
>>>the quirks and bugs of every possible user client.
>>
>>"Every possible user client" follows the same standards. Once
>>you've written the code that sends output conforming to the standards once
>>any client that can't handle it is a bug in the client's implementation of
>>said standard and therefore somebody else's problem.
>>
>
>The problem is that 90% of that standard is completely irrelevant to muds.
>Negotiation is also moot to my server. It doesn't dither around and negotiate
>with a client. It knows what the client will do. ;-)
>
>>>Inefficiency is maintaining parallel levels of client capability. Does
>>>the client do VT100, color, sound, MSP, compression, graphics, Pueblo,
>>>blah.. blah..
>>>
>>
>>Some of those protocols you can detect, others it's easy to revert to a
>>sensible default and allow the user to toggle it if you got it wrong.
>>
>>Once you've written any of these once in the server it's done. When you're
>>maintaining both the server and forcing them to use your client you've now
>>got to maintain the protocol in a) the server b) the win client and c) any
>>other platform you've ported to.
>>
>
>Mud protocols can be made much simpler. Note there are conflicts with
>layering all those protocols because they are all designed to accomplished
>different things. Adding a new protocol layer only serves to increase
>bandwidth. And bandwidth is the single most important performance
>concern for a server. I think implementing a single specific mud protocol is
>far simpler.
>
>--
>--* Jon A. Lambert - TychoMUD Email: jlsysinc#nospam,ix.netcom.com *--
>--* Mud Server Developer's Page <<A HREF="http://jlsysinc.home.netcom.com">http://jlsysinc.home.netcom.com</A>> *--
>--* "No Free man shall ever be debarred the use of arms." Thomas Jefferson *--
>
>
>
_______________________________________________
MUD-Dev mailing list
MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00011.html">[MUD-Dev] Fw: 16K mud server competition !</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00013.html">[MUD-Dev] META: Topic List - 1999</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00013.html">[MUD-Dev] META: Topic List - 1999</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00011.html">[MUD-Dev] Fw: 16K mud server competition !</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00012"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00012"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] characters per account</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00048" HREF="msg00048.html">Re: [MUD-Dev] characters per account</A></strong>,
Jon Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 05 Apr 2000, 00:37 GMT
<UL>
<LI><strong><A NAME="00054" HREF="msg00054.html">Re: [MUD-Dev] characters per account</A></strong>,
Darren Henderson <a href="mailto:darren#nighttide,net">darren#nighttide,net</a>, Wed 05 Apr 2000, 03:10 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00055" HREF="msg00055.html">Re: [MUD-Dev] characters per account</A></strong>,
Darren Henderson <a href="mailto:darren#nighttide,net">darren#nighttide,net</a>, Wed 05 Apr 2000, 03:28 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00013" HREF="msg00013.html">[MUD-Dev] META: Topic List - 1999</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
<LI><strong><A NAME="00012" HREF="msg00012.html">[MUD-Dev] Fw: DESIGN: XML?</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
<LI><strong><A NAME="00011" HREF="msg00011.html">[MUD-Dev] Fw: 16K mud server competition !</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00026" HREF="msg00026.html">Re: [MUD-Dev] Fw: 16K mud server competition !</A></strong>,
cg <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 04 Apr 2000, 02:26 GMT
</LI>
<LI><strong><A NAME="00028" HREF="msg00028.html">Re: [MUD-Dev] Fw: 16K mud server competition !</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 04 Apr 2000, 05:29 GMT
<UL>
<LI><strong><A NAME="00034" HREF="msg00034.html">Re: [MUD-Dev] Fw: 16K mud server competition !</A></strong>,
Jon Leonard <a href="mailto:jleonard#slimy,com">jleonard#slimy,com</a>, Tue 04 Apr 2000, 16:11 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>