[MUD-Dev] A new MUD-standard

[Kwon Ekstrom]

----- Original Message -----
From: "Bruce" <bruce at puremagic.com>

>> Now, this is still a very general list, the majority of the
>> concerns are with presentation, imho telnet is a wonderful
>> connection to handle text based games, although compression would
>> be nice (MCP???) to save bandwidth.  Now, here's how I'd use
>> NWLayout for this new standard...

> I assume that here, you are referring to zmud's Mud Compression
> Protocol.  It is unfortunate that they chose that moniker as it
> conflicts with the prior work done by people within the MOO
> community on (their) MCP. (http://www.moo.mud.org/mcp)

Actually I don't use zmud, I've always been more apt to use CRT to
connect to a *nix server and mud through tintin++, even tho it's
starting to become fairly out of date, it's fast, and doesn't bog
things down.  It wouldn't surprise me if there are multiple
implementations.  I have a program that acts like a proxy to use MCP
with the few games I play that use is.  Although I will admit that
compression is a good idea, if you can implement it where it doesn't
bog down the cpu with a large number of connections, which is why I
feel that should be optional... It'll allow the programmer to decide
whether to increase cpu at the cost of bandwidth, or vice versa

> Within the context of Mozilla, this could probably begin to build
> directly on some of the underpinnings of Chatzilla, modified to
> support a transport protocol, the concept of packages, etc.  Then,
> plugins could be written via anything that can implement an XPCOM
> interface, such as C++, JavaScript or Python.

*nod* Yeah, that's another reason to embed a browser, it gives the
power to write plugins to further enhance the client's capabilities.
A mud can use that protocol, with a plugin for more advanced features
as necessary.

>> I admit that this lends alot more power than is needed, but I'm
>> lazy, this is less work than defining my own specification, it
>> yields quicker results, and should have acceptable response times.
>> Naturally for graphical systems it would be a poor protocol, but
>> for the average mud home-brewed mud, it's an acceptable
>> arrangement.

> You're leaving out one of the big advantages. :) Having web
> integration in a server, and moving to a more advanced client is
> just a step towards bringing muds into a more modern age.  What
> about the MUD that starts to serve up RSS files describing recent
> events so that player-run sites (and the official site) can all get
> the same info directly from the source?  Going even further, with
> something like XML-RPC or SOAP, you could provide access to even
> more info, directly from the MUD.

> Interoperability and strong, existing deployed implementations are
> one of the advantages of using existing work.

Agreed, there are alot of big advantages for using web technology for
a MU*, in fact, a connection based application using current web
standards can be applied to business problems as well, this standard
can easily be adapted to create super intelligent web based sites.
It's the next logical step for the internet in general.  Naturally
maintaining a connection requires more resources than simply handling
several individual requests.

-- Kwon Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev