06 Oct, 2010, Mudder wrote in the 1st comment:
Votes: 0
So I remember hearing a little about mudstandards.org not being what it set out to be. I did a quick search on this forum and didn't get a result (I admit I didn't try hard)

Is it a good resource to get the protocols from? Is it actually a standard people are following?

Or should I search elsewhere for protocols like MXP, MCCP, etc?

Are there still differences with MXP for Mushclient and CMUD?
06 Oct, 2010, jurdendurden wrote in the 2nd comment:
Votes: 0
From what I read (which was around 20 posts), I feel like there is a lot to be garnered from mudstandards.org in the way of knowledge. There was indeed a bit of bickering toward the end, but all in all I did end up learning a tid bit just from the sliver I read.

However, I don't think anyone has actually picked up these standards formally yet… I may be wrong of course but it seems like the discussions just died off… with everyone packing up their toys and heading back to their own sandboxes.
06 Oct, 2010, Rudha wrote in the 3rd comment:
Votes: 0
Quote
it seems like the discussions just died off… with everyone packing up their toys and heading back to their own sandboxes.


That was my impression too though I don't understand quite why that came about.

Maya/Rudha
06 Oct, 2010, David Haley wrote in the 4th comment:
Votes: 0
Do you want the long version or the short version…? :wink:
It shouldn't be surprising that the community effort fell apart once it became clear that it wasn't actually a community effort.
06 Oct, 2010, Kaz wrote in the 5th comment:
Votes: 0
David Haley said:
Do you want the long version or the short version…? :wink:
It shouldn't be surprising that the community effort fell apart once it became clear that it wasn't actually a community effort.


I shall now do the amazing and agree with David Haley. :ghostface:

I do think it's a terrible waste of that resource. It had a great deal of potential, and it has been squandered.
06 Oct, 2010, Rudha wrote in the 6th comment:
Votes: 0
Its still useful in that their wiki at least givesa centralised location to find information on various mud related telopts.

Maya/Rudha
06 Oct, 2010, Scandum wrote in the 7th comment:
Votes: 0
The MCCP article on the Wiki contains an obsolete specification, but Nick Gammon refused to change it to the latest one, and my strong suspicion is that's because the last official MCCP specification is less agreeable with Nick's vision on how MCCP should work.

The whole GMCP discussion turned into the same kind of mess with conflicting viewpoints, and in the end IRE and Zugg withdrew from the discussion and finished it themselves.

The main problem is that pretty much all people are ill equipped to deal well with conflicts where opinions differ, and with the fact that someone has to be in charge and make the final decisions when no one is willing to compromise or work toward consensus.

So my conclusion is identical to Haley's, it's presented as a community effort while it was a loosely coupled group of individuals (IRE + Mudlet, Aardwolf, Zugg, Mushclient) wanting community support with no real say for the community in the matter, nor a clear understanding of their own relative worth, causing the core group itself to disintegrate, which I think was the true end of mudstandards.
06 Oct, 2010, Mudder wrote in the 8th comment:
Votes: 0
Hm, well that sucks.

I find I would like to eventually implement these protocols but I'm not sure which version is supported by which client. Overall it's just a silly thing to have to deal with.

Perhaps we could create a similar site that keeps up-to-date information on the protocols, which client implements them and up to what version, etc. So admins can have a single location to find accurate data.

I know that if, for example, MUSHclient supports MCCP version 2.0 (I am making up numbers) and cMUD supports all versions up to 4.5, I'd prefer to implement v. 2.0 or maybe detect the client and change the protocol accordingly.

Maybe the site wouldn't have the influence to create a standard that is upheld, but we could certainly do good.
06 Oct, 2010, KaVir wrote in the 9th comment:
Votes: 0
Scandum said:
So my conclusion is identical to Haley's, it's presented as a community effort while it was a loosely coupled group of individuals (IRE + Mudlet, Aardwolf, Zugg, Mushclient) wanting community support with no real say for the community in the matter,

For the record, I've also heard complaints about GMCP from Heiko (Mudlet), Lasher (Aardwolf) and Nick Gammon (MUSHclient). While there were plenty of individuals pushing their agendas on MudStandards, or even just arguing for the fun of it, I think the final decision regarding GMCP was only made by the two groups you named earlier.

Mudder said:
Perhaps we could create a similar site that keeps up-to-date information on the protocols, which client implements them and up to what version, etc. So admins can have a single location to find accurate data.

Try here: http://www.mudpedia.org/wiki/Comparison_...

Mudder said:
I know that if, for example, MUSHclient supports MCCP version 2.0 (I am making up numbers) and cMUD supports all versions up to 4.5, I'd prefer to implement v. 2.0 or maybe detect the client and change the protocol accordingly.

There are only two versions of MCCP, and I'm not aware of any clients that implement the first without also implementing the second - so you only need to support the second. They're separate protocols though, so you could in theory support both (and many muds do exactly that).

MXP is the only protocol I can think of off the top of my head that has multiple versions each offering different functionality. You can query the version and respond accordingly - but most clients that support MXP only seem to support a subset of the options. And the same seems to be true of most muds. In my opinion MXP is only really worth using for the links and perhaps the colours, anyway.
07 Oct, 2010, Scandum wrote in the 10th comment:
Votes: 0
Mudder said:
I find I would like to eventually implement these protocols but I'm not sure which version is supported by which client. Overall it's just a silly thing to have to deal with.

All clients support MCCP2 making MCCP1 obsolete. Not all servers support the option for the client to disable MCCP by sending IAC DONT MCCP, though following the last official specification they should.
07 Oct, 2010, Rudha wrote in the 11th comment:
Votes: 0
MCCP1 used malformed strings which were not proper TELOPTs, which is why MCCP2 was devised, as I understand it.

Maya/Rudha
07 Oct, 2010, KaVir wrote in the 12th comment:
Votes: 0
Rudha said:
MCCP1 used malformed strings which were not proper TELOPTs, which is why MCCP2 was devised, as I understand it.

In MCCP1, the server would send IAC SB COMPRESS WILL SE to indicate the start of compression - that's obviously not a valid sequence. MCCP2 changed it to IAC SB COMPRESS2 IAC SE, which still violates the telnet subnegotiation mechanism, but isn't quite as broken.
07 Oct, 2010, David Haley wrote in the 13th comment:
Votes: 0
KaVir said:
MCCP2 changed it to IAC SB COMPRESS2 IAC SE, which still violates the telnet subnegotiation mechanism, but isn't quite as broken.

As long as the will/do negotiation happens first, it's a valid message saying "everything henceforth will be compressed" (unless the argument is that the message requires a dummy parameter). Just because both sides have negotiated it doesn't mean that compression should begin at that instant.
07 Oct, 2010, Tyche wrote in the 14th comment:
Votes: 0
KaVir said:
Rudha said:
MCCP1 used malformed strings which were not proper TELOPTs, which is why MCCP2 was devised, as I understand it.

In MCCP1, the server would send IAC SB COMPRESS WILL SE to indicate the start of compression - that's obviously not a valid sequence. MCCP2 changed it to IAC SB COMPRESS2 IAC SE, which still violates the telnet subnegotiation mechanism, but isn't quite as broken.


And the proposed MCCP3 protocol lives within the Telnet subnegotiation mechanism, eliminates ambiguities in the specification, and allows error correction. ;-P
07 Oct, 2010, Runter wrote in the 15th comment:
Votes: 0
If someone ever invents a process to smelt mud-drama into bars of high quality ideas then mudstandards would be a good resource. A pipedream, that.
07 Oct, 2010, Rudha wrote in the 16th comment:
Votes: 0
Reading through the posts there, I'm given the impression that it was more a few people trying to get people to accept their ideas, more than a genuine effort to work collaboratively, though that's just what I take from it.

Maya/Rudha
08 Oct, 2010, Scandum wrote in the 17th comment:
Votes: 0
Most people suck at reasoning, brainstorming, or collaborating, on the bright side, they make up for it with their ability to rub each other's backs combined with an appeal to majority rule. I think you have to be in the middle of it to understand how frustrating a collaborative effort is, and most people bail out sooner rather than later, and wish they never had bothered to begin with.

I learned from the whole MSSP drama not to get overly involved, and I think most people knew from the get go that it wouldn't end well, but you still give it a half-assed shot for the hell of it.

One thing I'd like for MCCP would be client side data compression because client side MSDP data traffic can get pretty intense, all the server would have to do is respond with a DO to a WILL request from the client.
08 Oct, 2010, David Haley wrote in the 18th comment:
Votes: 0
Rudha said:
Reading through the posts there, I'm given the impression that it was more a few people trying to get people to accept their ideas, more than a genuine effort to work collaboratively, though that's just what I take from it.

If working collaboratively means not getting support for your requirements, it's pretty easy to understand why people don't want to make a "genuine effort to work collaboratively". The mapper thread was such an example, even if in the end of the day it was revealed that it was due to a terrible miscommunication. People thought that they were being told: "do it this way, or go away" – what kind of collaborative environment does that encourage?

Basically, people were coming at this from too many perspectives, and what probably killed it from the start was simply that there was little to no initial effort at establishing common ground before running around talking about protocols. It is obviously difficult to discuss the 'what' of a protocol when you haven't finished talking about the 'why'.

It didn't really help that people had different tolerances for detail-oriented discussions; for some it was impossible to avoid the details of a networking protocol (like what bytes one actually sends) and for others those were boring, tedious and irrelevant. This created a fair amount of friction.

I think it's too easy to say that people were all motivated by some hidden agenda and weren't actually trying to get something done. As Scandum said you have to be actually involved in it, or to have been involved in similar projects, to understand the tension that can come between otherwise very well-intentioned people. I think that many people were, in fact, trying to build something. It's just that as said above there was no effort at creating common ground, and it's pretty much impossible to work together if you don't even understand each other in the first place.

It's not like standards processes are smooth in other parts of the world. There are any number of very public, very bitter arguments about any number of standards, held by actual professionals who have very real things at stake in the discussions. I think that MudStandards fell victim to the same problems that any standards discussion has, and because the results of the discussion were not going to dramatically affect everybody, it was easier to just give up. In our world, you can wander off and write a plugin for a client to get your stuff supported. We've seen several times that even so-called 'standards' get variable support from different clients (think MXP), so it's not like a proper standard would have actually changed the face of the MUD world in terms of being able to talk to every client. So yes, because people didn't have to care, they simply didn't.
08 Oct, 2010, Kaz wrote in the 19th comment:
Votes: 0
As I've said, I feel that this was a missed opportunity, so rather than continuing this post-mortem conversation, I have a tangential question. Mudstandards achieved an objective, and that was to obtain outside input on the proposed GMCP-n-ATCP2 protocol. It lived while it did that, and then died. If it hadn't died, I wouldn't ask this question if there would be any kind of competition, but…

Is it worth creating a new site, getting the attention of codebase and client implementers and creating a proper standards collation and creation effort?
08 Oct, 2010, KaVir wrote in the 20th comment:
Votes: 0
Kaz said:
Is it worth creating a new site, getting the attention of codebase and client implementers and creating a proper standards collation and creation effort?

If you could get the attention of server and client developers, sure. But I think the chances of that are extremely slim.

IRE represents five large muds, and they got Aardwolf (an even larger mud) on board. This naturally attracted the interest of the big client developers, which in turn attracted the interest of other server developers. Of course the side-effect of this was that when IRE decided to cease discussions and do their own thing, most of the client developers followed them.

If you want to get the attention of the client developers, you need to wave some really big muds in front of their noses. But to get the big muds on board, you generally need to wave the major clients in front of their noses. Chicken and egg. Someone has to take the first step, and it really needs to be either one of the major client developers, or the owner of one of the really big muds - and even that may not be enough to convince people, after the last fiasco.

It might be worthwhile to write up all the existing protocols though - sort of like the MudStandards wiki. Perhaps add it as a Mudpedia section. That way at least all the protocols would be in one centralised location, where server and client developers could reference them.
0.0/62