Out of mobid curiosity, whatever did happen with that whole mudstandards thing? I havent the time or interest to start reading through the forum drama, and the wiki seems like a copypaste job. Its a pity, I think. With all these redundant protocols - Im looking at you MCP/ATCP/ATCP2 - some sort of standardisation would seem like a worthy goal. Its a pain trying to work out failure paths for spotty client support.

The short version is that there was disagreement about how to run the standardization process. Some people felt it was important to discuss low-level details; other people thought that that was a nit-picking waste of time. Eventually IRE and Zugg decided to do cut out the community process and make executive decisions. Part of the problem is that a decision process was never made clear, so nobody really knew how consensus was to be established. As it turned out, it would appear that the IRE developers were not so much asking for a community project, but more brainstorming of sorts, so that they could decide what they liked and implement that.

One might note that the IRE+Zugg ATCP2 is running into issues now that were foreseen much earlier, such as the strange format that is-but-isn't JSON, and have in fact missed the point about structured data by inserting custom formats inside strings rather than sending JSON objects (which was part of the whole point).

If you want the long story, well, the forum's there for perusal…

Seems to me that there was a lot of pedantics argued certainly. Ive been playing with MSDP and thats kind of why I like it in a manner if speaking - it trims away a lot of the fat of other implementations.

Perhaps with some more common code for MSSP and MSDP out there, we can encourage people to accept open standards. ATCP2 isnt really a standard if it deviates frequently, IMHO.

Maya/Rudha

PS: thanks for pointing out those licenses. Ill look into them.

It seems to me that something as basic as a data syntax isn't pedantry, it's necessity… if you can't reliably encode and decode the data you're sending, how can you possibly attempt to do anything with it?

ATCP2 fell apart because in part because it was attempting to do too much without defining clear goals. It was simultaneously a syntax definition for data exchange (which became frankenjson) and a semantics defintion for game data (the atcp.room, atcp.char stuff). But this distinction was never really made clear, and there was a lot of arguing about game-specific stuff. People wanted to enshrine some particular game's way of working as The One True Way, as part of the same specification defining the syntax.

MSDP avoids this by being closer to a syntax definition; if you go back to MSDP's early days there were all the same arguments about the impossibility of fixing Grand Unified Semantics for All Possible Games as "official MSDP variables". (In fact, the attempt to do that is the weakest part of the spec.) MSDP as it is used by KaVir also deviates from its "standard", in that it uses other variables than the ones canonized by the spec, but that's just how things are. Too many people in ATCP2 were attempting to lock in their semantics in a protocol meant for many different MUDs. For example, there was a considerable debate about mapping and rooms because some people saw no use in hiding data from players whereas other people thought it was important to their games.

So ATCP2 could have done much better as a data exchange format if they had stuck to one thing at a time. It would basically have been a telnet negotiation for subsequent JSON-format message exchange. This would have been a better format than MSDP, as it would have had proper structure from the get-go while still being a very simple format to parse if you don't care about the structure.

Such a protocol would need a very clear syntax definition to start with, and then a very clear core package set for things like caching and enabling other packages, but the actual game semantics should have been left to MUDs, or at least MUD families; a package like ATCP.Diku or ATCP.Smaug would have made more sense than some attempt at making ATCP.Char to handle every possible character representation in all MUDs.

The reportable MSDP variables are "mere suggestions for MUDs wanting to implement MSDP", while "configurable variable support is optional". Even the generic MSDP commands are optional.

Yes, hence why I used quotation marks… I guess that might have been too subtle, but I was using them to highlight that the standard is not a formal, fixed standard. This is what makes it easy to use. The point I was making is that there's no reason why one would not use at least the core of ATCP2 the same way: as a data passing protocol.

Perhaps I should of qualified my statements somewhat. To me, as an outsider looking in, it appears discussion of ATCP2 broke down over the fine details before consensus had been established on the actual design phase of the thing.

Maya/rudha

It's certainly true that many people came in with very different backgrounds and therefore ideas of what the protocol was supposed to do, and this created confusion. A lot of the fine detail discussions were part of discovering what other people wanted, I think.

That said, the discussions about the actual data syntax were not really inappropriate, especially when people started producing specification documentation, and even more so when you note that this protocol has been released into the wild as a 'standard' with all the open issues that were being discussed at the time (and that have become features now).

It was my understanding that the core packages are not an optional part of the ATCP1 or ATCP2/GMCP specifications.

I found negotiating ATCP with CMUD somewhat analogous with plucking a cork from the backside of a monkey that's suffering from chronic diarrhea.

You need to have a good foundation before you start building a house or all kinds of problems will crop up.

And that, KaVir, is one of the more disturbing and yet frighteningly intiguing analogies I have heard.

Maya/Rudha

Well, yes. That is part of the problem that I am describing. That decision was not at all necessary and came from people's experience with ATCP1. They were not thinking of it as generic structured data but as "IRE's game data messages version 2". Even if you are to specify certain packages as required for ATCP2, you should not pick semantics packages like room, char, etc., but rather strictly data-transport-oriented packages like caching. (And caching would be optional.)

But yes, as it is now, ZuggRE's ATCP2 specification does not make those packages optional, correct. That part of the standard was still being discussed when they made their decision.

Incidentally, the fact that they used the same data model is one of the reasons why I will not call it anything other than ATCP2; that's basically all it is, a "re-syntaxing" of the same data messages (complete with the same bizarre embedded custom structure formats inside strings – they missed the whole point of the move to structured data…).


Well, I kind of hate to say it, but when a developer proposes to use a standard just to explicitly break it for "ease of parsing" (?!?) it's not surprising that other standards are not followed too well. :thinking:

They should have just demanded everyone embed lua.

In the interest of full disclosure: just trolling.

We do actually have protocol 102 for embedded Lua, and it's even got fairly decent client-side support (for now at least).

It's not really embedded Lua. It's a subset of Lua's table syntax. It happens to be implemented in MUSHclient by feeding it to a Lua interpreter, but that is not a requirement (nor is it necessarily desirable).

Embedding scripts in out of band transmissions? I can't see anything bad happening with that at all.

Yeah, I'm being facetious..

Anyways, good to know Im not the only one who sees GMDP as ATCP2 and little else.

Maya/Rudha

Pardon the double post, but I have only heard of this protocol 102 in passing from Aardwolf's news and google doesnt seem to want to be helpful turning up information about it. Is there somewhere I can read about it?

Maya/Rudha

I think MSDP tables translate fairly well to Lua tables, though I must admit the way JSON handles arrays (though more verbose) allows for very elegant parsing.

Not sure if a parser that translates MSDP tables to Lua tables has the same potential security issues.

Pooh tables

Rudha: I believe the relevant thread is this one.


The issue came up because the "suggested protocol" (it's not really a standard, and when proposed for standardization things were different) states merely that the data is a Lua table. So you could send something like this:

{hp=100, max_hp=120, foo=(function f() do_something_bad() end) ()}

such that when executed by the interpreter to reconstitute the message, the bad function is executed.

If you translated MSDP data to Lua tables using a trusted mechanism, there is no reason why you'd be evaluating anything other than a very strict subset of tables, namely a recursive definition like what I gave in the thread on Nick's forum:

you then have no risk of running functions.


One big advantage of Lua and JSON is that they are trivially human readable as they do not use non-printable characters as separators. They also come with full structure "for free".

http://lpmuds.net/suspicious_quotes.jpg