02 Mar, 2009, David Haley wrote in the 61st comment:
Votes: 0
elanthis said:
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)

Not sure I follow why you think this isn't an issue. MUD admins will have to make sure they handle the protocol correctly in their server if they want to talk to the snippet. You argue that most people are very bad at this, so why isn't it a problem to force MUD admins to handle it correctly?
02 Mar, 2009, Scandum wrote in the 62nd comment:
Votes: 0
The way I assume it'll be implemented is that a crawler connects, and updates the database with all submitted values. Your suggestion would require the extra step of clearing all database entries for that mud, I don't see how that is feasible for muds who only do a partial MSSP implementation. Imagine TMC adopts this and a mud only uses MSSP to report online players and uptime, following the protocol would require TMC to clear most of the mud's entry.

Lets say TMC is alright with this, and MUDs are forced to submit all data, then there is the forward compatibility issue. If "CLANS" ? "1" : "0" is added muds who haven't stayed up to spec will have their clan status on TMC set to "0" until they add the "CLANS" value.

Muds can respond with "0" for integers and "" for string values to clear them, and with a good implementation it shouldn't result in messy code.

To me this is the most sane behavior, but I'm open to clear practical objections.
02 Mar, 2009, elanthis wrote in the 63rd comment:
Votes: 0
MUD servers already have working (enough) code for responding to simple negotiation (DO, DONT, etc.). It's in the handling of larger sub-negotiation requests that most MUDs run into trouble. The server end of MSSP does not need to receive or parse sub-negotiation requests, only send them. Spitting out a chunk of well-formed protocol is far easier than editing it… just like it's dead-easy to spit out even relatively complex XML, but parsing it properly requires quite a bit of code. (Albeit, the vast majority of professionals I've run into just try to use regexes and basic string manipulation to parse it… I recently had to undo a change to a custom XML API that happened to change the order two attributes were output in because one of our customers top-dollar consultants was doing /first="(.*)" second="(.*)"/ to read our response, and we couldn't get the client to fix their code. I wish to $DEITY that that had been an isolated case, too. :/ )
02 Mar, 2009, elanthis wrote in the 64th comment:
Votes: 0
Scandum said:
The way I assume it'll be implemented is that a crawler connects, and updates the database with all submitted values. Your suggestion would require the extra step of clearing all database entries for that mud, I don't see how that is feasible for muds who only do a partial MSSP implementation. Imagine TMC adopts this and a mud only uses MSSP to report online players and uptime, following the protocol would require TMC to clear most of the mud's entry.


If the MUD only has a partial implementation then how could the MUD possibly have a previously reported MSSP value?

You seem to be assuming that a crawler developer is going to be taking the MSSP results and having them totally overwrite manually-entered data in a listing databases. That would be the definition of stupid (I will submit it to Websters). If a crawler developer does that, let him deal with the screwed up consequences.

An intelligently written crawler is going to have separate database entries for the manually-entered data and the MSSP-reported data. Whether it displays both sets, has MSSP values override manual entries, or has manual entries override MSSP values is up to the crawler site, depending on how much faith they put in MSSP.
02 Mar, 2009, Scandum wrote in the 65th comment:
Votes: 0
elanthis said:
You seem to be assuming that a crawler developer is going to be taking the MSSP results and having them totally overwrite manually-entered data in a listing databases.

Yes, because that's the point of MSSP.
02 Mar, 2009, elanthis wrote in the 66th comment:
Votes: 0
Scandum said:
Yes, because that's the point of MSSP.


I am quite confident that the crawlers aren't going to use it the way you think they will. Something about 5 years experience developing software that does more or less exactly what MSSP does (aggregation of automatically-collected data combined with user-provided content), albeit for far larger sets of data in far more financially-sensitive contexts. If you're going to let your bruised ego get in the way of accepting sound advice, then I suppose people will just have to deal with the fact that reality and the MSSP specification don't agree with each other.

Fact: If a crawler site ever automatically and permanently overwrites anything a user took the time to type in manually, that crawler site is going to end up on people's shit list VERY quickly.

Crawlers will be storing the manually-entered data separate from the MSSP provided data. When MSSP responds to a crawler, the MSSP data will be cleared but not the manually-entered data. Crawlers written by anybody with a clue are going to store MSSP data in separate tables/columns/etc. and then selectively combine the manually-entered and MSSP data as the site sees fit. If the MUD operator wanted the data to be dynamically provided then he most likely would simply not enter any data in the site's listing forms, where-as the MUD operators using only the status bits of the MSSP will be entering a lot of data in the MUD listing site. Hence, if a MUD advertises a value and then ceases advertising it, the listing sites would just revert to showing the non-MSSP version of the data (if any), because it would never have been foolishly erased.
02 Mar, 2009, Scandum wrote in the 67th comment:
Votes: 0
Nice appeal to authority, but other than that I don't think you're making a convincing argument. Lets leave it at that MUDs will be safest providing all known variables, and I added to the protocol:

Variables and Values
——————————————————————————–
If a variable is omitted it is assumed the previously reported value for that
value should be used. The "PLAYERS" and "UPTIME" variables should always be
included. For ease of parsing, variables and values cannot contain the MSSP_VAL,
MSSP_VAR, IAC, or NUL byte. The value can be an empty string unless an
integer value is expected. Given the data traffic generated by MSSP is very
small at less than 1 KB it is strongly suggested to always send all variables
and their values.
02 Mar, 2009, Scandum wrote in the 68th comment:
Votes: 0
For crawlers, length of the mssp telnet subnegotiation is returned.

#define     TELOPT_MSSP          70   /* used to send mud server information */

#define MSSP_VAR 1
#define MSSP_VAL 2

int recv_sb_mssp(unsigned char *src, int srclen)
{
char var[MAX_STRING_LENGTH], val[MAX_STRING_LENGTH];
char *pto;
int i;

var[0] = val[0] = i = 0;

while (i < srclen && src[i] != SE)
{
switch (src[i])
{
case MSSP_VAR:
i++;
pto = var;

while (i < srclen && src[i] >= 3 && src[i] != IAC)
{
*pto++ = src[i++];
}
*pto = 0;
break;

case MSSP_VAL:
i++;
pto = val;

while (i < srclen && src[i] >= 3 && src[i] != IAC)
{
*pto++ = src[i++];
}
*pto = 0;

printf("%-20s %s\n", var, val);
break;

default:
i++;
break;
}
}
return UMIN(i + 1, srclen);
}
02 Mar, 2009, elanthis wrote in the 69th comment:
Votes: 0
Scandum said:
Nice appeal to authority, but other than that I don't think you're making a convincing argument.


At least I'm making an argument instead of going "blah blah blah no don't wanna…"

Quote
Lets leave it at that MUDs will be safest providing all known variables


Which falls apart in the face of extensions, especially if a MUD developer decides to experiment with them a bit. Which is quite likely. Essentially, once they try one, they're stuck with sending it with an empty value for a good long while to ensure crawlers clear it out.

I really do not understand why you are being so stubborn about holding on to a broken feature, especially given that you don't even have a realistic reason for keeping it.
03 Mar, 2009, Scandum wrote in the 70th comment:
Votes: 0
I think forward and backward compatibility is a pretty good argument. Like I already explained, MSSP is supposed to be a replacement of manual updates, not an addition, hence I fully expect mud directories to overwrite manually entered data. If a MUD messes up their entry with MSSP that's their fault, not the crawler's. What your suggestion does is force a lot of unneeded complexity for the crawlers. Also, the protocol suggests sending out all variables, so sending empty values would be following protocol.

We can go back and forth on this for quite some time, but unless you provide a compelling argument you're just throwing out "blah blah blah" to me as well. Besides, your suggestion would mean that if a mud does not send its host, port, or ip, those values should be blanked. I doubt that'd be helpful.
03 Mar, 2009, David Haley wrote in the 71st comment:
Votes: 0
I could make an argument about why it's silly to use the last value on omission, but elanthis has done so very well already.

It's ridiculous to assume that once a value is ever given, it is supposed to remain forevermore in crawler memory.

What's even more dumb about all this is that you say yourself:
Scandum's protocol spec said:
Given the data traffic generated by MSSP is very
small at less than 1 KB it is strongly suggested to always send all variables
and their values.

Why introduce all the complexity in the first place if the default modus operandi is to send everything…?

Scandum, you're really going out of your way to shoot this protocol in the foot. Yes, something is better than nothing, in some sense, but this could go a whole lot further if you weren't getting in your own way like this. :thinking:
03 Mar, 2009, Kline wrote in the 72nd comment:
Votes: 0
So any technical arguments aside, this is fairly off-putting for me (and maybe others? I don't know) to even care to implement just due to attitude about things so far, Scandum. I'm not trying to troll, flame, or whatever, just be honest. You have an idea for a protocol, and I like it, it sounds cool and would be something neat and help keep index sites more up-to-date if they implement it – awesome so far! Yet…You want feedback and suggestions but continually stick to your guns of "Well it's my idea. I'm doing it my way. I've already added it into TinTin because I can. Now my way has even more virtue of being the right way, because a client is already supporting it."

And while you expect MSSP to replace all manual updates – can you really enforce that? I can see the argument of both sides, replacing or supplementing, but I don't know many people who would be willing to run a site that gets populated with automated data without review/intervention; reliable as it may be.
03 Mar, 2009, kiasyn wrote in the 73rd comment:
Votes: 0
Are there any MUD servers currently running MSSP to test on?
03 Mar, 2009, David Haley wrote in the 74th comment:
Votes: 0
It might be nice to wait for MSSP to settle down a bit before running amok implementing it on servers. I'm not sure there's much consensus yet…
03 Mar, 2009, Scandum wrote in the 75th comment:
Votes: 0
slackhalla.org 4321 supports MSSP as currently defined.
03 Mar, 2009, Scandum wrote in the 76th comment:
Votes: 0
Kline said:
So any technical arguments aside, this is fairly off-putting for me (and maybe others? I don't know) to even care to implement just due to attitude about things so far, Scandum. I'm not trying to troll, flame, or whatever, just be honest. You have an idea for a protocol, and I like it, it sounds cool and would be something neat and help keep index sites more up-to-date if they implement it – awesome so far! Yet…You want feedback and suggestions but continually stick to your guns of "Well it's my idea. I'm doing it my way. I've already added it into TinTin because I can. Now my way has even more virtue of being the right way, because a client is already supporting it."

And while you expect MSSP to replace all manual updates – can you really enforce that? I can see the argument of both sides, replacing or supplementing, but I don't know many people who would be willing to run a site that gets populated with automated data without review/intervention; reliable as it may be.

I have listened to advise however and I think the protocol has come a long way. I've also pointed out from the start I'm willing to put in the work instead of just doing the talk.

Things are however problematic if I fundamentally disagree with a position.

Keep in mind that I originally wanted to implement MSSP as DH and elanthis are suggesting now, so it's not so much that I'm sticking to my guns, but considered the options and changed my mind, it doesn't help when there are no good logical arguments against a position, other than "I think people will react in this or that fashion and it won't be good". TMC currently has unreviewed updates, it seems to work so far.
03 Mar, 2009, kiasyn wrote in the 77th comment:
Votes: 0
Either your test server or the spec you have defined is incorrect.
MSSP_VAL        1
MSSP_VAR 2


these values should be the other way around:

MSSP_VAR        1
MSSP_VAL 2
03 Mar, 2009, kiasyn wrote in the 78th comment:
Votes: 0
My testing has also shown that you are not wrapping your output with ""

IE
"PLAYERS"
"Medieval Fantasy"

etc.

which leaves me confused as hell as to how i know when a string ends :)
03 Mar, 2009, Scandum wrote in the 79th comment:
Votes: 0
Doh, nice catch. Given the var comes before the val it should be:

MSSP_VAR 1
MSSP_VAL 2

I updated the protocol.
03 Mar, 2009, Scandum wrote in the 80th comment:
Votes: 0
The " " in the protocol indicates that it's a string, not that the " " should actually be there.

Should I list this in a clearer way?

A string starts with MSSP_VAR or MSSP_VAL and ends with MSSP_VAL MSSP_VAR or IAC Your typical format is: IAC SB TELOPT_MSSP MSSP_VAR "BLA" MSSP_VAL "BLI" MSSP_VAR "BLO" MSSP_VAL "BLU" IAC SE
60.0/154