[MUD-Dev] Clients based on Netscape 5?

[Chris Gray]

[Caliban:]

:I disagree. An HTTP connection is, at its heart, a telnet connection -- a teln
:connection which abides by certain communication standards, much as any BBS
:transaction was at its heart a simple modem connect over which the systems
:communicated. Front-end mailers, netmail, FIDO technology, all of these were
:simply limited command sets on which the industry standardised; HTTP is no
:different. If Netscape is properly designed, then the HTTP connection object's
:parent would be a raw telnet connect without option negotiation, which is easi
:extended and turned into a proper telnet client through a simple implementatio
:of DO/DON'T/WILL/WON'T handling.

Well, I've seen the telnet docs (so I could implement some of it in my
text agents), but I haven't seen any HTTP specs. My *impression* had been
that there was little in common, other than that they both basically send
text back and forth. I guess I'm having trouble seeing what is to be gained
by what you're talking about (and I'm not sure just what you are saying,
so that could be the reason).

:Here's my immediate take on it. You could throw out the entire MUD programming
:language as it stands, and replace it with JavaScript. The MUSH server itself
:could run a modified concept of the document-object model already supported

I'd have to disagree here. JavaScript was never meant for that sort of thing.
Java itself would be much better. A server needs an efficient language, that
operates in the domain of the entities within the MUD. Java can do that, but
from what I know of JavaScript, it only does it very indirectly, through
callouts to stuff written in other languages. That might be OK for a client,
but I can't see it for a server.

You could make a MUD server (whether MUSH-like or otherwise) that sends out
HTML (possibly extended) documents for things like room discriptions, etc.
However, I think things are tending more towards dynamically generated
descriptions and images (as per the discussions going on in this list), in
which case it might be easier to stick to something custom. The difficulty
and work is in the dynamic generation, not in a simple protocol to send
the stuff back and forth, so not having to abide by some largely irrelevant
rules in a protocol designed for something else would make the job easier.
In other words, use something designed to do what you want to do, rather
than hacking something designed for something else.

Now, as you mention in the next paragraph, Netscape has lots of tools
within it that are useful, so extracting those might be worthwhile. I'm
just not convinced that its general framework and way of doing things is
of much value for a MUD. It could be *made* to work, but at what cost?

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA