MXP/Extending MUD Technologies (Was Re: [MUD-Dev] Object Representations?)

[KevinL]

>>> Nathan Clemons wrote
> A "holdout" who happens to still be interested in technologies of this
> nature. :)

You're not the only one.  We've started down the road of creating something to 
hopefully address your points, and others.  My thinking at the moment is as 
follows:

Start with a very simple XML spec of some sort - we've started with 
something that duplicates the necessary (for us) bits of any OO RPC system 
(http://www.bofh.net.au/mud/doc/zwiki/MoebiusXML), simply because that allows 
us to encapsulate _any_ scheme quickly and easily for testing, by calling 
remote methods (decodeMethodBlah(data)).  It's envisaged that when we work out 
a proper scheme, this all will change, although I am growing quite fond of the 
system as it stands ;)

Run this over something like BXXP 
(http://xml.resource.org/profiles/BXXP/bxxp.html) to solve the problems we 
don't want to solve (BXXP allows for opening multiple channels on a single TCP 
pipe, so you can communicate while large blocks of data are flowing etc.  
Theoretically, this could also be used for opening a data channel and a 
control channel, or whatever).

Encapsulate _everything_ - if everything's encapsulated, then the whole issue 
of "is this player data, or is this server data" vanishes.  I run a seperate 
port - 5050 - to handle client connections, but we could easily auto-negotiate 
on login or something.

Treat the client like a server - I want my clients to potentially have the 
same level of flexibility as the server, at least at the protocol level.  That 
way, we loose nothing and bind ourselves into nothing.

We're currently looking at a bunch of ways to make message objects - that 
lispish setup was nice, someone else posted us an LP-based one that looked 
kinda neat too.  Once those are sorted, we look at rendering into XMLish, into 
telnet, maybe into web - whatever.

The system as it stands can support either calling particular render methods 
for everything, to test your own render methods, or it can support starting to 
define particular commands (ie. "every mud client shall offer a "loginRequest" 
command, which takes a list of variable definitions and a command 
name.  It will retrieve data for each of those variables according to their 
definitions, and call the provided command name with those variables 
provided.").  That lets us play with both a fully generic rpcish setup, and a 
more specific "mudXML" design, depending on what looks more useful.

To be honest, the big problem with this stuff is not technical - these are, in 
the main, solved problems.  The big issue is political - how the hell do you 
get a bunch of mud admins to actually agree on anything as interesting as a 
spec for server/server and server/client chatter?

Oh, and the fact that there's a few other options out there clouds things - 
each alternative solves it's own problem domain (sometimes well, sometimes 
not).  I have a weakness for generic solutions, so that's the direction I'm 
taking, but it's possibly not as efficient in first draft as some other 
alternatives.  More to the point, each alternative is niched - it works with 
it's own codebase, and that's it.

I'd dearly love to be able to offer AI people an object view of the world - say 
"all events will be received as this sort of structure, with these sorts of 
things defined" - that would work on basically _any_ mud.  Let's face it, 
we're all sending information about surroundings and events - I reckon it 
_can_ be laid out in an extensible way, so that even where you might not 
recognise a particular mud's particular little portion of cool stuff, you can 
get the general gist of what's happening enough to function.

End rant ;)

> 
> It's still my feeling, that with care:
> 
> * HTML-like styles make it easy for server-side developers and clients to
> understand. Perhaps something more XML-ish is in order, but I wouldn't
> know. Never played with the stuff. Something along this line is also
> easier for the clients to develop and render to the viewer/player.
> 
> * The ability to display images is going to become a very big "plus" in
> creating an ambiance or environment.
> 
> * Security is a matter of degree. I wouldn't allow people to pass HTML
> tags to my CGIs in most circumstances, nor would I allow players to pass
> MXP tags to the MUD, in most circumstances. The amount that the client has
> to "trust" the server, IMHO, is extremely limited.
> 
> Maybe MXP isn't the right technology for expanding the technical
> capabilites of the current text-bound (IMHO, read: moribund) flavor of MUD
> codebases currently extant.
> 
> What other technologies are there? Still open to suggestion. :)
> 
> -- 
> Nathan P. Clemons                       "Peace favor your code."
> nathan at windsofstorm.net                 ICQ: 2810688
> (v) 401.725.6061			(f) 603.372.9737
> 
> 
> 
> 
> _______________________________________________
> MUD-Dev mailing list
> MUD-Dev at kanga.nu
> http://www.kanga.nu/lists/listinfo/mud-dev
> 

KevinL





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