19 Mar, 2009, Scandum wrote in the 1st comment:
Votes: 0
I discussed the matter with TMC and it looks like a plain text alternative alongside the telnet version could be an option. I propose the following:

A server can put MSSP PLAINTEXT on a single line in the greeting, if the crawler sees this it will send: MSSP-PLAINTEXT. The server will respond to this with:

\r\nMSSP-START\r\nvariable:value\r\nvariable:value\r\nMSSP-END\r\n

If a server wants to send multiple values for one variable it can send: variable:value:value:value\r\n

Variables and values should be the same as the telnet ones.

The : \r or \n characters shouldn't be used as part of a variable or value.


If people want to use another tag that's fine, but I think this stays close enough to the telnet version to work and allow crawlers to reuse most of the code.
19 Mar, 2009, kiasyn wrote in the 2nd comment:
Votes: 0
I will be supporting: http://lpmuds.net/forum/index.php?topic=... and the telnet MSSP, but not this.
19 Mar, 2009, Scandum wrote in the 3rd comment:
Votes: 0
Any particular reason?

I don't particularly care for the extra space, and especially not using {{ }} {{ }} instead of multiple : to separate values.

I think that'd be a lot cleaner.

Using the same tags is not an issue.
19 Mar, 2009, kiasyn wrote in the 4th comment:
Votes: 0
I don't like servers having to put MSSP PLAINTEXT in their greeting. The one in the link requires the client to initiate it, which makes a lot more sense to me.

I dont like the {} either, but this has not been set in stone yet.
19 Mar, 2009, elanthis wrote in the 5th comment:
Votes: 0
Gotta agree, that curly bracket separator syntax is funky. I think the : separate sucks too (not as bad, though). Just repeating the key makes the most sense. I see no reason to support repeated keys _and_ a separator, though… using multiple keys isn't any more difficult for the MUD operator but supporting the separators (especially the bracket one) is quite a bit more difficult for the crawler developer.
19 Mar, 2009, kiasyn wrote in the 6th comment:
Votes: 0
elanthis said:
Gotta agree, that curly bracket separator syntax is funky. I think the : separate sucks too (not as bad, though). Just repeating the key makes the most sense. I see no reason to support repeated keys _and_ a separator, though… using multiple keys isn't any more difficult for the MUD operator but supporting the separators (especially the bracket one) is quite a bit more difficult for the crawler developer.
\

self-agree bump thingy. i also agree just accepting the key more than once
19 Mar, 2009, Guest wrote in the 7th comment:
Votes: 0
Either accept the key more than once or use comma separation on the values. The bracket thing just seems weird to me.
19 Mar, 2009, Kayle wrote in the 8th comment:
Votes: 0
What about a tab (\t) delimited separator?
19 Mar, 2009, Cratylus wrote in the 9th comment:
Votes: 0
Quote
What about a tab (\t) delimited separator?


I admit this made me uncomfy when quix suggested it, but the
more I think about it, the more sense it makes.

I think it would be cool to have multiple vals on one line be an accepted
way of doing things. If people are really opposed to it, yknow, what can I do,
but I think it would be cool.

The \t delimiter seems the least intrusive way to me.

-Crat
http://lpmuds.net
19 Mar, 2009, wrkq wrote in the 10th comment:
Votes: 0
Both commas and colons might ocur in the mud name, for example. What then?
Either tabsep, or repeated keys. From programming point of view, there's not much of a difference in terms of amount of work.
19 Mar, 2009, Igabod wrote in the 11th comment:
Votes: 0
Kayle said:
What about a tab (\t) delimited separator?


Cratylus said:
Quote
What about a tab (\t) delimited separator?


I admit this made me uncomfy when quix suggested it, but the
more I think about it, the more sense it makes.

I think it would be cool to have multiple vals on one line be an accepted
way of doing things. If people are really opposed to it, yknow, what can I do,
but I think it would be cool.

The \t delimiter seems the least intrusive way to me.

-Crat
http://lpmuds.net


That was kayle not quix, YAY yet another useless post from Igabod!
19 Mar, 2009, Scandum wrote in the 12th comment:
Votes: 0
So is the current consensus with using the following:

variable\tvalue\r\nvariable\tvalue\tvalue\tvalue\r\n

And for the tags:

MSSP-REQUEST
MSSP-REPLY-START
MSSP-REPLY-END

?
19 Mar, 2009, Cratylus wrote in the 13th comment:
Votes: 0
Thus far that is what I see as consensus, but there's no need to rush it. I'd
like to get more opinions.

-Crat
19 Mar, 2009, David Haley wrote in the 14th comment:
Votes: 0
As soon as you have a delimiter, you need to worry about escaping that delimiter if it could appear in the response text. Really, even newlines might appear in the response text, for instance in a 'description' field. So some kind of escaping is needed. Therefore, whether the delimiter is ',' ':' or whatever isn't terribly relevant except for aesthetics; in all cases you need to escape it. Tab separation doesn't help because, while tabs are indeed very unlikely to appear and need to be delimited, you still need to escape newlines that might appear in the output.
19 Mar, 2009, wrkq wrote in the 15th comment:
Votes: 0
DESCRIPTION: first-line
DESCRIPTION: second-line
DESCRIPTION: third-line
seems OK to me. Crat, may I ask why would you prefer one delimited line instead of this?

Other option - every field is terminated by CRLF. You could decided that in-field lines are terminated by LF only. But this will heavily cripple readability of the output if you'd for some reason want to issue a MSSP-REQUEST by hand. Staircase effect.

(and anyway, aren't newlines completely disallowed in all fields?)
19 Mar, 2009, Scandum wrote in the 16th comment:
Votes: 0
As pointed out on TMC a ':' is pretty common in Mud names, and the same for ','.

I think tabs are the perfect choice, and description fields or anything of that nature should be wrapped by the crawler using tabs for paragraphs.

Thinking about it this really is very good, and adding escaping rules at this point with no indication it'll ever be needed seems premature. All values really should be in the 32 to 126 range.
19 Mar, 2009, David Haley wrote in the 17th comment:
Votes: 0
Adding escaping later is a lot harder than adding escaping at the very beginning. We could indeed send out a description in several iterations, but that also means that it's impossible to have several multi-line values for a field.
19 Mar, 2009, wrkq wrote in the 18th comment:
Votes: 0
I don't think that you may need a multiple-value multiline field.
What else than description and the *-NOTES fields might need multiline, anyway?

Other option is carrying the 'continuation' information in the key.
For example, make every line than the first prefixed by +.
FIELDNAME: item 1 line 1
+FIELDNAME: item 1 line 2
FIELDNAME: item 2 of the same field
FIELDNAME: and another
+FIELDNAME: spanning two lines.
Or no field name, just "+:" or ":" for "continuation of last entry"

Other thing you may want to encode in that way is the field type (text, bool, integer, list of strings, whatever…)

$FIELD: string
#OTHER: number
19 Mar, 2009, David Haley wrote in the 19th comment:
Votes: 0
At some point don't the contortions to get around the need to escape become more complex than the escaping itself? :thinking:
19 Mar, 2009, elanthis wrote in the 20th comment:
Votes: 0
wrkq said:
Other option is carrying the 'continuation' information in the key.
For example, make every line than the first prefixed by +.
FIELDNAME: item 1 line 1
+FIELDNAME: item 1 line 2


If you're going to use continuations for lines that have embedded newlines, PLEASE PLEASE don't invent yet another new way of doing it, but just do it the same way MIME and HTTP headers do it. Then people writing crawlers can just use all of the existing code (which many languages ship with as a built-in standard library feature) to parse the data.

You don't need to reinvent the wheel.
0.0/84