I have a few "yes but what if"'s myself. That was one of my original
concerns regarding the straitjacketed feel of some of the categories.

Here's a thought. Maybe each category should have a "-NOTES" field associated with it…


"UPSINCE: 1230434401\r\n"
"UPSINCE-NOTES: last hotboot 1234567890\r\n"

"CLASSES: 4\r\n"
"CLASSES-NOTES: these are optional, classless available\r\n"

"RACES: 1\r\n"
"RACES-NOTES: two of the classes are a kind of race\r\n"

"ROOMS: auto-generated\r\n"
"ROOMS-NOTES: generated rooms persist after creation, currently ~5000\r\n"

-Crat
http://lpmuds.net

If you can be bothered to add passing the previous boot time along to the new process, sure. Common sense applies I think.


Hrm, hadn't thought about that yet. They could use the port option multiple times reporting their main port last.


So hard to enforce they can fill in whatever.


That's up to you, but I don't think anyone would give you the stink eye if you included those.


Entirely up to you, common sense applies.


The definition is entirely up to you. I think ultimately it's the community that needs to enforce that muds don't fill in random values.


Could be classless, but classless generally refers to an open skill system. Not sure how I'd handle a variable for an open skill system, suggestions anyone?

Your example would work just fine. After some thought though, I would advocate the use of a standard markup language instead (such as XML, but there are certainly others). This opens up the use of third-party tools to validate/process/format the reply, making it potentially easier to integrate the service into a MUD aggregation site.

But also potentially more difficult.

Well, the format he gave is a standardized format, you just might not know it. :wink: (It's Tcl, for the record.) XML is far too heavyweight IMO, and XML libraries tend to be a PITA to use. The Tcl format is so utterly simple that I could write you a parser in almost any language in less than an hour.

Doesn't look like Tcl to me, but it's been 15 or more years since I last played with it. But to stay on point, do select a standardized markup/format (XML, YAML, SDL, whatever) so that the option is there to take advantage of third-party tools to process it.

Well, to be precise, the format is more like: key: {tcl value}. The only complexity here is representing the values which can be lists with lists inside; the key/val part itself is trivial. Compared to other markup languages, like YAML (AFAIK) and especially XML, the Tcl list/string format is extremely simple. I think it would be silly to adopt something so heavy as XML just to be able to use third-party tools.

Maybe start a different thread to discuss MSSP for Donkeys? I'd call it for Dummies, but that's ™.

Sure, just as soon as you start one for MSSP for Elitist Client Writers who Think that Everyone Will Adopt their Genius Protocol. :rolleyes:

I already did, you're in it.

This is the OP. This thread is on topic.

-Crat
http://lpmuds.net

Again, XML is just one possibility (I'm not married to it), though I'm not sure why you consider it to be more heavyweight than the other options. There are XML libraries available for almost every language (some less feature rich than others), just as there are libraries available for the other options. Granted, the data we're talking about to date is pretty flat, but could evolve into lists and trees over time. Future proofing is always a worthy goal.

I'm not sure I like the idea of having a format that imposes too much structure on the data, because several fields we're talking about aren't really structured to begin with – there's a lot of free-form exceptions cropping up. I would rather "future proof" the data with a version field than trying to over-engineer all possible future extensions right now. I have this opinion as I would like to get something done sooner rather than later.

I'm neither especially for nor especially against having
the *option* to return values in XML form. I'm perfectly
cool with having the request string optionally append "-XML"
(or whatever) to get extra fancy rich doodads. Fine by me.

But the base-protocol-anyone-can-use I think should avoid
stuff that requires "libraries". At its simplest (and I'd
like to get the walking done before the running) I think
it should be something as easily eye-parsable as machine-.

-Crat
http://lpmuds.net

Let's circle back for a moment… As I understand it, MUD sites (not MUD clients) are the consumers of the MSSP data. It's been ages since I developed any web content (e.g., Microsoft IE didn't exist back then), but if I'm safe in assuming (which remains to be seen) that dynamic content is still typically generated by embedded or local scripts, then taking advantage of an existing library for a well-known format provides an easy way to parse and format the MSSP response.

BTW, this also plays into the approach of putting the MSSP request and response into the normal i/o stream rather than using telnet options, with the script taking advantage of an existing socket library to connect to the server, send the MSSP request, scrape off the MSSP response, and disconnect.

I might not have made the point clearly enough earlier, but I can provide said libraries quickly for major programming languages. The format is dead simple, easily readable by the human eye, easily readable by machines. In fact, I wouldn't be surprised if there were already libraries to parse exactly this kind of string – maybe even explicitly Tcl parsing libraries.

If a library exists for the example format, then great - use it. But certainly don't re-invent the wheel otherwise. There are several formats available, that are in wide use, and are sure to be supported into the future.

Are the formats you suggested as simple and easy to read as the Tcl strings/lists? XML certainly is not. YAML doesn't seem so to me. I'm not aware of the third one you gave. Anyhow, if they're not, I would say that's a fairly compelling reason to avoid them.

Yes. Here are a few for comparison…

Crat's psuedo Tcl:

"UPSINCE: 1230434401\r\n"
"UPSINCE-NOTES: last hotboot 1234567890\r\n"
"CLASSES: 4\r\n"
"CLASSES-NOTES: these are optional, classless available\r\n"
"RACES: 1\r\n"
"RACES-NOTES: two of the classes are a kind of race\r\n"
"ROOMS: auto-generated\r\n"
"ROOMS-NOTES: generated rooms persist after creation, currently ~5000\r\n"

XML:

<UPSINCE>1230434401</UPSINCE>
<UPSINCE-NOTES>last hotboot 1234567890</UPSINCE-NOTES>
<CLASSES>4</CLASSES>
<CLASSES-NOTES>these are optional, classless available</CLASSES-NOTES>
<RACES>1</RACES>
<RACES-NOTES>two of the classes are a kind of race</RACES-NOTES>
<ROOMS>auto-generated</ROOMS>
<ROOMS-NOTES>generated rooms persist after creation, currently ~5000</ROOMS-NOTES>

YAML:

UPSINCE: 1230434401
UPSINCE-NOTES: last hotboot 1234567890
CLASSES: 4
CLASSES-NOTES: these are optional, classless available
RACES: 1
RACES-NOTES: two of the classes are a kind of race
ROOMS: auto-generated
ROOMS-NOTES: generated rooms persist after creation, currently ~5000

SDL:

UPSINCE "1230434401"
UPSINCE-NOTES "last hotboot 1234567890"
CLASSES "4"
CLASSES-NOTES "these are optional, classless available"
RACES "1"
RACES-NOTES "two of the classes are a kind of race"
ROOMS "auto-generated"
ROOMS-NOTES "generated rooms persist after creation, currently ~5000"

The current data set is flat, and can be accessed as a simple attribute map, but if we expect the data to evolve, and the attribute to potentially be more complex (e.g., lists and trees), then I would strongly recommend adopting one of the standard formats that will already have a library to parse it with.

Those examples are the uninteresting ones – it gets more interesting when you have lists. I was sort of hoping for an example that dealt with the list example he gave. It can handle lists without any issue.

Again, it's possible to extend the protocol by versioning it – that lets us cross bridges when we get there and all that. If however you have a use case for trees, that would be reason to do it now.