David Haley
Wizard
Group: Members
Posts: 6,912
Joined: Jun 30, 2007
|
#46 id:20939 Posted Feb 28, 2009, 3:21 pm
|
elanthis said:The first is that some MUDs have no website, which I call shenanigans on unless someone can actually prove that there is a MUD with a real playerbase and no Web presence at all.
Maybe small MUDs that don't have a playerbase yet but want to get one, and to do so want more exposure, want to be consumers of this listing protocol too...
elanthis said:Should namespacing of keys be explicitly mentioned in the spec so that variables specific to certain classes of MUD (e.g. Diku) can be clearly defined as such and also allow future MUD families to get safely define new variables without fear of a collision with another family's variables?
Actually, that's a pretty good idea. You now have the problem of who "owns" the standard and therefore gets to decide on new families should they come up, but that's a social problem, not a technical one.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,404
Joined: Aug 8, 2006
|
#47 id:20940 Posted Feb 28, 2009, 4:26 pm
|
elanthis said:However, from experience with ZMP, I suggest that you aim for using a pure-text output format that does not rely on binary codes, as the current protocol does.
Can you name one scripting language that cannot handle control and 8 bit characters? The problem of ZMP is that it uses NUL bytes which makes it tedious to implement in string based languages. MSSP doesn't have that issue, and I think the protocol currently states that NUL and IAC are not allowed within variables and values. As it is there are roughly two hundred muds that have a partial telnet implementation, and it seems the logical route to take since it's peanuts inserting MSSP in a well written telopt handler. Unless you can provide good evidence that \c-a and \c-b and \xFF are hard to handle in popular scripting languages, there's no difference between <var>:<val>\r\n and \c-a<var>\c-b<val>.
elanthis said:Stateful Protocol:The idea of compressing output by only sometimes sending a full set of data forces the protocol to become stateful.
I definitely don't want omitted values to automatically be assumed zero because that'll make it quite difficult for crawlers. I guess I should emphasis in the protocol that 1Kb of data is so minimal that there's no need for compression of any kind.
elanthis said:I simply would like to see a solid, well-stated case made on how it is preferable to reusing existing, extensible, Web-based technologies designed for exactly this sort of use.
The mud crawlers are already up and running. I think that's the main advantage, they don't need an extra url, just check for IAC WILL MSSP, send back IAC DO MSSP, and check for IAC SB MSSP <stuff> IAC SE. Telnet clients will simply ignore the IAC WILL MSSP, like they blissfully ignore IAC WILL MCCP.
elanthis said:What resources are available for maintaining a list of known variables and their meanings once the initial spec is out?
TinTin++ will support MSSP which will provide a standard for debugging mud servers wanting to support MSSP, and I can keep a page up to date on the tintin site as well. I think that should be enough to keep things organized for a while.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,404
Joined: Aug 8, 2006
|
#48 id:20941 Posted Feb 28, 2009, 4:33 pm
|
David Haley said:You now have the problem of who "owns" the standard and therefore gets to decide on new families should they come up, but that's a social problem, not a technical one.
Mud sites that adopt it will likely further develop the standard.
|
|
|
|
|
|
|
|
|
elanthis
Wizard
Group: Members
Posts: 772
Joined: Feb 26, 2008
|
#52 id:20951 Posted Mar 1, 2009, 12:41 am
|
Scandum said:Can you name one scripting language that cannot handle control and 8 bit characters? The problem of ZMP is that it uses NUL bytes which makes it tedious to implement in string based languages.
I said "easy relative to dealing with text" and not "cannot do it at all." Don't overestimate the average idiot, either. If it's harder than dead simple, it's too hard. Seriously. I have very real experience with this, dude. There really is a difference between ':' and '\x01' when it comes to the average coder. One is something they "get" right off the bat. The other is something most don't even know is possible. Most MUD coders do not even truly understand the fundamentals of either general software development nor the specifics of their language's syntax and standard library. When it comes to MUDs, aim for the least common denominator.
It is overall a minor point. I wholeheartedly believe the protocol will have higher uptake if you follow my advice, but using the non-textual codes won't cause it fail entirely.
Quote:MSSP doesn't have that issue, and I think the protocol currently states that NUL and IAC are not allowed within variables and values.
That's fine.
Quote:
I definitely don't want omitted values to automatically be assumed zero because that'll make it quite difficult for crawlers. I guess I should emphasis in the protocol that 1Kb of data is so minimal that there's no need for compression of any kind.
If zero means something different than the empty string, then yes, this is true. Omitted should mean "there is no value for this at all, nothing meaningful, do not display it or index it or anything, because this value does not exist." That is a very, very, very different thing than "use the last value you saw."
A clear example of my issue with your proposed behavior: a put up a Diku-derived MUD. I add MSSP, and add a number of Diku-related MSSP variables. After a couple years I put up my rewrite (built off of SocketMUD). None of the Diku-related variables make sense in my new codebase, so I clearly didn't add them to the new codebase's MSSP implementation. Frustratingly, however, all of the MUD crawlers keep listing those values in my MUD's entry, because the spec says that the crawlers have to use the last value if I don't omit a variable. I have to add cruft to my new shiny MUD to work around the protocol to force crawlers to forgot variables sent by an entirely different codebae.
If omitted variables means "does not exist, do not use" then the problem goes away. The new codebase does not send those variables. The crawlers simply delete all prior data when reading in an MSSP block from a MUD. Each MSSP request should list all relevant data every time, so neither the server nor the crawler has any reason to care in the least about what got sent last time -- either the data got sent with the new result or the MUD developer decided that the data become irrelevant and removed it. The crawlers will be easier to implement, too.
I cannot stress this enough. The "use last value" behavior is WRONG and BAD and KILLS BABIES. Don't do it.
Quote:The mud crawlers are already up and running.
Good enough for me.
Is there a list of known crawlers?
Quote:
TinTin++ will support MSSP which will provide a standard for debugging mud servers wanting to support MSSP, and I can keep a page up to date on the tintin site as well. I think that should be enough to keep things organized for a while.
Alright. I would think about getting it somewhere with a dedicated forum asap, as at least then MUD authors have a standard place (referenced in the specification) to go to for informally hashing out extensions. Obviously it would be neat to have someone formalizing those specs, but just being able to easily look up what other people are using in their extensions is really good enough for the most part.
I would also just recommend clearly stating in the spec that custom variables should have namespacing. The semi-official ones might just use a simple DIKU. prefix or the like. MUD-specific ones should probably be recommended to use their game hostname or something, e.g. COM.HOSTSITE.MYMUD.VARIABLE. The clearer you spell out "good practice" the more likely people will actually follow it.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
Scandum
Wizard
Group: Members
Posts: 1,404
Joined: Aug 8, 2006
|
#53 id:20954 Posted Mar 1, 2009, 4:30 pm
|
elanthis said:Is there a list of known crawlers?
Not really. I know that mudstats and tmc have one up and running.
elanthis said:Alright. I would think about getting it somewhere with a dedicated forum asap, as at least then MUD authors have a standard place (referenced in the specification) to go to for informally hashing out extensions. Obviously it would be neat to have someone formalizing those specs, but just being able to easily look up what other people are using in their extensions is really good enough for the most part.
Best left to the crawler sites in my opinion. Adding pre-fixes is just gonna be annoying.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,404
Joined: Aug 8, 2006
|
#54 id:20964 Posted Mar 2, 2009, 10:47 am
|
Moving this here so there is somewhat of an announcement topics.
David Haley said:So you have completely settled on the idea of using telnet options, have you?
Given how dumbed down MSSP currently is it's just telnet compatible. The clearest advantage is that the MUD server can announce that it uses MSSP to any client. This isn't possible without being annoying with the alternative protocols suggested which makes it unaccessible to mud clients that want to automatically and transparently set up connection information.
And as observed before, there's no difference other than that it uses \x01 \x02 and \xFF instead of : \r and \n.
The argument that it's easy to plug-in into muds with a telnet handler has been ignored as well, opposed to the hack job that a different implementation would imply.
|
|
|
|
|
|
|
David Haley
Wizard
Group: Members
Posts: 6,912
Joined: Jun 30, 2007
|
#57 id:20967 Posted Mar 2, 2009, 11:09 am
|
Well, we can either treat this as somebody's personal baby, or we can treat it as something that would actually be useful to the community. If people actually care about this being valuable to everybody, you need the latter. If people are just giving opinions to give opinions, then sure, who cares, go with the former.
|
|
|
|
|
|
|
elanthis
Wizard
Group: Members
Posts: 772
Joined: Feb 26, 2008
|
#60 id:20975 Posted Mar 2, 2009, 1:44 pm
|
David Haley said:Out of curiosity, who all here except for Scandum thinks that the telnet options are the way to go? Just trying to get a feel for the consensus -- if I'm the only one who thinks they're a bad idea, ...
I don't think it's bad from a protocol design perspective. I believe it would have more uptake in clients if it were not TELNET-based, but if the target audience that Scandum cares about the most is crawlers, I think TELNET is fine. I have very real experience with trying to get ZMP implemented in clients, which uses TELNET the exact same way MSSP does... and most clients suck balls and require a complete rewrite of their protocol handlers to add ZMP. So do almost all servers (which admittedly, MSSP doesn't have to worry about, because it only sends the big chunks of data from the server, not to it). Given that use in regular clients isn't really the target audience, here, though, probably not worth being too worried about it. So long as all the crawlers are being written by smart people, it should be fine.
If we want to start talking about _ideal_ protocols, we should start from scratch and dump TELNET altogether and replace it with a message-oriented protocol designed specifically for data-rich text gaming. Idealism and reality don't tend to see eye to eye all too often, though. :)
The only huge major goof that will make MSSP suck I see is the use-last-value-on-omit semantics, which Scandum appears to just be ignoring the arguments against... at least, he hasn't responded to my detailed reasoning against it nor has he updated the spec. I have a feeling that all crawlers will just forgot omitted values anyway, but it would be ideal if the spec just required sane behavior to begin with.
I think Scandum's intent with that whole previous-value thing might've been solely for the sake of regular MUD clients that want periodic status updates. If you want that behavior without ****ing up MSSP for crawlers, I would suggest changing the spec to state that when a value is omitted, a client should keep the _previously specified value from the same connection, in any_. Then MUDs can remove variables at their leisure with no fear of crawlers retaining the removed variable's value indefinitely.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
