If the old standard is used one thing that'll have to be changed is the way arrays are handled, maybe see if there's some useful feedback if I take it to mudstandards.

Why would arrays need to change?

MSDP arrays aren't arrays, but repeat redefinitions of a variable value. Syntax wise: $report=x=y=z is equal to: $report=x$report=y$report=z, or in standard notation: report = x, y, z - and I don't think that's valid syntax in most languages.

For a real array you'd have to use: $report = {=x=y=z} and a 2d array would be: $report = {={=a=b=c} ={=a=b=c}}, while it makes sense once you wrap your head around it, I think it'll be too alien to make MSDP successful with muds wanting to use nested data.

@KaVir

How appealing is the following to you when it comes to sending and parsing it?

MSDP_VAR "AFFECTS" MSDP_VAL MSDP_OPEN MSDP_OPEN MSDP_VAL "icon" MSDP_VAL "type" MSDP_VAL "name" MSDP_VAL "duration" MSDP_CLOSE MSDP_VAL MSDP_OPEN MSDP_VAR "icon" MSDP_VAL "type" MSDP_VAL "name" MSDP_VAL "duration" MSDP_CLOSE MSDP_CLOSE

As consensus and compromise currently lie, that'll be the format that'll be natively supported by tt++. The old array format will remain an option as well (aside from restricting byte 3 and 4 there's no change), but without nesting only 1d arrays are supported natively.

I've come to understand some people strongly dislike nesting, and with MSDP server developers are free to not use nesting (technically servers don't even need to support receiving variables), but I strongly believe it should be available for those who wish to use it.

As far as I can see, your proposal is fully backward compatible with the current specification. As such I have no problem with it.

Alright. I've got the nested associative array part build into tt++, just need to handle arrays. I'll look into getting a test server ready as well.

Who exactly is so opposed to nesting? It seems like a rather innocuous concept…

Incidentally, MSDP is a great example of how prototypes become fixed in stone. Lasher says that he liked it because it was apparently so rock-stable, and yet it'd only been "released" for a relatively short period of time, was/is still under active development, etc. (To be clear, this is not intended to criticize you, Scandum.)

MSDP may be relatively new, but IMO the specification is much clearer and more straightforward than the other out-of-band protocols. My main concern was that redesigning (as opposed to expanding) the specification at this stage, just as other developers are starting to get involved, could undermine confidence in the stability of the protocol.

I'm currently aware of seven out-of-band protocols, all of which can be used to do the same sort of thing. If developers decide to step back and wait for MSDP to mature a bit more, they may well end up going with another protocol instead. It doesn't really need to be said, but the more muds there are that support MSDP, the greater the chance of clients adding it. As one of the largest muds, Aardwolf's choice of protocol will have a big impact on client development.

Lets see if I can name them all, NEW-ENVIRON, ATCP, GMCP, ZMP, MCP, MXP, and SFXP?

Nesting is pretty much what will finalize MSDP as that'll cover the full range in a typeless protocol, so I think a redesign would have been a good thing in the long run. Looks like 3 people total is gonna be all the input, but I guess people are tired of butting heads over protocols.

You missed MSDP itself ;) The others were 102 and ConQUEST's new protocol (94). I hadn't considered NEW-ENVIRON, that's a good point. SFXP and MCP are in-band, like older versions of MXP.


I firmly believe that MSDP's simplicity is its strength. It doesn't force you to add loads of special variables and packages, or require you to use odd pseudo-standards, or define what format the values should be sent in, etc. Even once you've added nesting to the spec, there's nothing forcing someone to use it if they'd rather send their values in JSON or something instead.

As I said earlier in the thread, I view ATCP/2 as the works-for-all-muds protocol, and MSDP as the tailored-to-each-mud protocol.

So basically, you are arguing that everybody should forge ahead, in order to get lots of people supporting something? It seems to me that there be dragons that way… and it seems like a wonderful way to cement what could be mistakes or at least shortcomings even though you're still in the prototyping phase. (Isn't the whole point of a prototyping phase to be willing to make changes?) It seems somewhat irritating to have your hand forced just because you want Lasher to support the protocol and not use another one. (Is somebody keeping score?)

In fact, MSDP's place as a 'standard' is somewhat odd when you say things like this:
"As I said earlier in the thread, I view ATCP/2 as the works-for-all-muds protocol, and MSDP as the tailored-to-each-mud protocol."

If this is the case, why do you really care about what other MUDs do with it? You'll need to tailor clients to the MUD's particular packages anyhow. What exactly is it that you're asking to be standardized, the ability to parse out the subneg sequences? (Why does that even need explicit client support when you can do it with plugins?)

Incidentally, ATCP/2 is also just a data transfer protocol, with a package system layered on top of it. Your perception is due to the rather poor "marketing" of what the point actually was, which was to present structured data; at a basic level, the only difference between MSDP and ATCP2 is the data format.

Clients will be expected to support specific GMCP packages, where as with MSDP clients are expected to only support sending and receiving variables.

But that's what I'm saying: ATCP2 doesn't require the plethora of packages, strictly speaking; the format of "<message name> <json>" (for a sane implementation of JSON, at least, not the mess they chose to use) is just a way to move around data. Now it happens that they also want to layer a bunch of other stuff on top of it, but in the end of the day, fundamentally at least, it is just a way of sending message names with associated data. For some reason the talk of 'packages' scared a bunch of people and gave some really bad impressions, but when you look at the fundamentals ATCP2 (at least conceptually, again not the direction ZuggRE chose to pursue) it's not different from MSDP.

Not just clients, I suspect, but also servers. I had to remove my "psuedo MSDP" ATCP package in the end, because CMUD started bombarding the mud with messages as soon as I'd negotiated ATCP.

GMCP defines core packages and a JSON(ish) data format as part of its specification, and I think most server and client implementations are going to assume that the specification has been followed at the other end. Sending your own out-of-band data format through GMCP would be like sending it through MSP or MCCP - technically possible, but likely to cause problems, because you're not following the specification.

Having been using MSDP for a few months now, I find its simplicity and flexibility very appealing, and it's good to see other developers taking an interest as well - more client support means more choice for my players.

I still am not sure why you say this. Let's say CMUD implements MSDP. Are players going to get all the maps or icons you implemented? No… not unless you (or somebody) writes the entire drawing plugin.

The only thing that will happen is that some data will be available, and I suppose that's better than nothing, but it won't really mean "more choice" in terms of getting the features you implemented for MUSHclient.


The whole point of ATCP1+ATCP2 is to send out-of-band data so I don't know what you're objecting to here.

MSDP is a protocol aimed primarily at plugin/script developers. If their preferred client supports MSDP, then they have the choice of using it to improve their plugins and scripts. If their preferred client doesn't support MSDP, then they don't have that choice.

CMUD supports open protocols, therefore CMUD users have the choice of using MSDP to create maps and icons. Mudlet doesn't support open protocols or MSDP, therefore Mudlet users don't have that choice.

The ATCP and GMCP specifications define more than just "out-of-band data", they define core packages and a specific format for data values. MSDP does neither, making it simpler and more flexible, and these are the reasons why some developers find it appealing.

But here's the really great thing: If you don't like MSDP, you don't have to add it to your mud! Scandum won't break your kneecaps with a baseball bat if you'd rather use ATCP, GMCP, ZMP, 102, 94, MXP, MCP, SFXP or NEW-ENVIRON. You could even make up your own protocol, without fear of finding a horse's severed head in your bed the next morning. In fact, why not do that? If you think MSDP is bad, go and write up a proposal for a new protocol.

This seems to be an argument against Mudlet not supporting open protocols.


The point was merely that fundamentally ATCP2 is just a data passing protocol. The packages layered on top are separate.


Uh……. ok. I don't think anybody's kneecaps were threatened or horses heads were removed anywhere. :wink:


What I think is "bad" here is not MSDP but the very dangerous insistence on turning prototypes into final, production products just because somebody happens to be using it. (In fact, you're worried about people who are only just considering it!) Many potentially good protocols have been screwed up because of attitudes exactly like this. (ATCP2 is another good example, actually.)

It is unfortunate that Mudlet doesn't support open protocols, however as I said earlier "the more muds there are that support MSDP, the greater the chance of clients adding it. As one of the largest muds, Aardwolf's choice of protocol will have a big impact on client development". Mudlet added support for 102 specifically because of Aardwolf, so if Aardwolf decides to implement MSDP then there is a greater chance of Mudlet either adding open protocol support, or explicitly implementing MSDP - either outcome would be fine with me, as it would give Mudlet users the choice of using MSDP to improve any scripts they create/distribute for my mud.

MSP is also fundementally a "data passing protocol", and could be used to transmit out-of-band data for maps and energy bars. However that would be outside the scope of its specification. The ATCP and GMCP specifications define core packages and specific data value formats that I do not like, and appears to lack the options I require. The MSDP specification is clear and straightforward, it does exactly what I want, and it's open-ended enough that it can be adapted to the needs of individual muds without breaking the specification or requiring redundant packages to be added.

I don't want to see MSDP turned into "ATCP-lite" - otherwise I'd just implement GMCP. I like MSDP because it's simple, it's flexible, and it tastes like cake. I can understand Scandum wanting to add nesting, but I am very wary of introducing unnecessary complexity, as this would undermine the incentive to use MSDP and greatly detract from its appeal.

MSDP already is "ATCP-Lite", and in fact isn't really that different from ATCP1. It's all just passing messages with associated data. ATCP1 didn't even have the JSON stuff. Incidentally, although I understand why you might not like ATCP2, I'm not sure what is missing in ATCP1 for you. It seems to give you functionally the same thing, except that it uses a very slightly different format for separating values, variables, etc.

I think that nesting has pretty clear use cases and provides clearly useful functionality. I'm not sure what "unnecessary complexity" you had in mind. But I object strongly to the notion that a protocol which can be so easily improved is being held back merely on the basis that some people are considering it. Just because a person or two rush ahead, should we hamper its development forever? That seems a little extreme to me. Unnecessary complexity to you might be a fundamentally useful feature to somebody else. Structured data is the future (well, actually, MUDs are only just catching up to the present) and not having nested data is a really bad thing. It's very frustrating to see what is a prototype become magically fixed in stone; it smells of laziness and/or premature decision-making.

Mudlet is using QTsockets, and doesn't have a lot of cruft yet. It was quite easy to modify Mudlet to instead call my own network library instead of QT's.