Mud standards – telnet options – not a standard yet.

It has been a couple of years now since we worked on handling data exchange between the MUD and client using telnet option negotiation. With hindsight, using telnet option 102 for this was probably a mistake as we have since learned that ATCP could have done the same thing, so could ZMP, and a number of other options. The existing support for ‘102’ in the Aardwolf code will remain in place, but no further work will be done on it.

Fast forward to the beginning of 2010. The mud community realizes we need better interfaces and an important part of that is new standards for client/server exchange. I was excited to be invited to mudstandards.org earlier this year to take part in discussions to design exactly that.

Authors of several clients were already on board including Mushclient, Zmud/Cmud, Mudlet, Tintin++ and possibly others. Admins of several large MUDs were involved and authors of a number of MUD codebases. I really thought we’d come up with something useful.

Trying to avoid laying blame anywhere in particular, what we ended up with was (100% in my opinion only):

• A failed attempt at standards. Two major client authors in disagreement to the point that each declares they are leaving the forum.
• Many other community members left with the impression that mudstandards.org was only ever created to “rubber stamp IRE ideas”. As this is an opinion piece anyway, I think it’s ok to state that I do think IRE and everyone else involved started out with a good faith attempt to have open discussions leading to a widely adopted standard. It quickly became obvious that agreement was not going to be reached anytime soon if ever. IRE just had to move forward with something, much the same way as we now are.
• A draft protocol called GMCP, or ATCP2, depending who you ask. There is even argument over the name.
• No built-in support for ATCP2 in Mushclient, basic support in Cmud and full support in Mudlet. All come with lots of disclaimers that the standard is still very subject to change.
• Protocol itself is “kind of” JSON. “Kind of JSON” to me is a waste of time. I don’t like the bloat of JSON but it does have the advantage of being a standard. The Facebook API uses JSON, a number of other large services use JSON. There is value in sucking up the bloat and going with a JSON based protocol, if we stick to the standard strictly. If we don’t, I might as well do what I always do and go-it-alone with a streamlined but completely proprietary approach.

So here I am, wanting to work on a new version of our Mushclient, wanting to work on some Flex stuff, and with no clearer picture of which protocol to use. This is one of those situations where being a smaller MUD would be better, we’d just choose what we choose and nobody would care. Our experience with the “102” protocol has shown that whatever we pick people are going to request that client authors support it and it will become something of a rogue “standard” even if that was never the intent.

One thing I have seen that looks very promising is MSDP which very nicely covers everything we wanted to do with the “102” protocol originally, is very expandable, does not have the JSON overhead of ATCP2/GMCP and will be both easy to implement and easy to modify our existing scripts for. The downside of this protocol is very limited support in most clients and MUDs and if we wanted to use the protocol to exchange binary data, the values ‘1’ and ‘2’ need to be wrapped or escaped somehow.

Even MSDP has issues (for us). If I’m going to avoid JSON to avoid overhead then I’m going to avoid overhead. I’m not going to use variables like “EXPERIENCE_TNL” when just “TNL” will do. If another MUD has other meanings for TNL so what? Does it matter with compression? Possibly not, but if we’re forsaking a standard for efficiency then we might as well optimize the efficiency on day 1 when it’s easiest. The MSDP protocol does support this though, and the variables listed are suggestions and guidelines only.

So far I’m leaning towards using MSDP for all the work I do myself and for the client/server communication with the new Mushclient package then implementing ATCP2/GMCP longer term for the more general client support.

Maybe MSDP will gain more traction and this won’t be necessary, or maybe future discussions will be more successful and the two protocols will merge. I wouldn’t count on it. In the meantime, we need to move ahead with something, knowing it isn’t perfect but is better than what we have today and is a whole lot better than nothing.

I wrote this because of many queries about what we plan to do. Most of these queries come from Aardwolf players, but a good number of them come from client authors and other, hmmm, “interested third parties”. Some people a very passionate about this stuff – there is no intent to offend anyone here, only to pick what I believe is the best approach for us right now and to explain the reasoning behind it in one place that we can refer people to.

Nothing written here is set in stone, feedback appreciated…