[MUD-Dev] A new MUD-standard

[J C Lawrence]

On Thu, 22 Feb 2001 16:44:15 -0700 
Kwon Ekstrom <justice at softhome.net> wrote:

> ----- Original Message ----- From: "J C Lawrence" <claw at kanga.nu>
>> Custom is not necessarily better.  You need to define your
>> problem *and* its various requirements and so forth before you
>> can properly evaluate "better".

> Well said J C.

> When I approached the problem of a new client standard, the a list
> of requirements came to mind.  Following your line of thought,
> those requirements are:

>   Presentation Bandwidth Usability Learning curve

I usually like going into considerable detail in writing a
functional definition of the requirement:

  Someone using the client must be able to do XXX easily.

  It must be possible to do YYY.

  ZZZ aspects of the game state must be represented clearly to the
  user, and must be actively updated and maintained in with current
  state without the user having to request an update.

etc.

You can get extremely detailed in these things, and it is often
valuable to do so.

> Which immediately pointed me directly at web technology.  

Web protocols work well for many things, tho PULL access semantics
don't suit everything (which is where the new RPC layers start being
really interesting).

> Which is why I've been thinking of using NWLayout as a rendering
> engine.  

I'm not familiar enough with NWLayout to comment at all really.  

> I can only imagine how much time and energy it would take to write
> an engine with the range of display options of html.  Instead of
> defining what it is, you define how it looks, if that's not good
> enough, you can use xml with css or xsl to send data and have it
> displayed as necessary.

My temptation would be to use an XML based format for the transport
layer, and then do local interpretation and presentation of the
results.  This helps make your Mode/View/Controller abstractions
fairly clean.

> A few people have mentioned how xml was too slow, and I'd like to
> know what they were trying to do with it, for a text environ, it'd
> be pretty fast imho, but for a graphical environ, you're better
> off with a binary protocol, no reason to convert to xml then
> convert back to binary, etc...

There are som many variables inside there that its impossible to
speak well in generalities.  If you're going to design a protocol,
based on XML or not, which is performance sensitive, then you had
better analyse your data model very carefully, as to how your
protocol represents and translates that model, and how it may
optimise the performance sensitive aspects of it.  This is mostly
pretty special-case stuff that is concerned with a specific
implementation, or at least a specific abstraction of a problem set,
and thus can't really be generalised from.

A graphical game that uses shallow simple schema XML formats to
transfer tags which reference locally stored and manipulated blobs
etc could be quite efficient depending on transaction rates, latency
requirements, etc etc etc etc ad infinitum.  It could also be a real
bitch just due to the parsing overhead for every protocol
transaction.  Or not.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev