I can invent a use case, but for the given data it could already be better organized as…

XML:

<UPSINCE>
  <TIME>1230434401</TIME>
  <NOTES>last hotboot 1234567890</NOTES>
</UPSINCE>

YAML:

UPSINCE:
  TIME: 1230434401
  NOTES: last hotboot 1234567890

SDL:

UPSINCE {
  TIME "1230434401"
  NOTES "last hotboot 1234567890"
}

Unless I minsunderstood, I think this is what David was getting at:



If this is your idea of the XML markup:


Then it's utterly trivial and there's no practical reason it can't be included
as an optional output type.

-Crat
http://lpmuds.net

Well yes, the markup in any of the formats is rather uninteresting with the current data set. But I think the point is being missed here… Rather than specifying a (possibly) proprietary markup, adopt an existing markup that is widely supported, and future proof.

For the record, Tcl is not proprietary.
I also think the point is being missed about how something can be made future proof before we even know what kind of future extensions are possible.

If I could see into the future, I wouldn't be spending my time here :tongue:
The point is that these other markups have the capability to describe more complex data, and libraries to parse them, if it becomes necessary. There's no cost to adopting one of them, there's upside and no downside, so I'm surprised there's resistance to doing so.

Yes, there is a cost in adopting them: it's more annoying to generate the data, and for that matter, IMO it is more annoying to parse them. My experience with XML parsers, for example, has always been rather unpleasant. Maybe YAML/SDL are easier to work with.

The thing is that until we have a need for complex data structures, it's a whole lot easier to just assume that a thing is either a string, or a list of things. This is very, very easy to parse. If your data format can handle complex things like attributes, nesting, and so forth, the data structures returned by the parser are likely to be more complex.

As I have said, we can leave the option open trivially by having a version specifier, or an output format specifier as Crat has suggested. Problem solved.

Personally I'm not resistin nothin. I think it's a fine
idea and I think that when the basic no-frills-just-strings-
and-lists thing is done, I'll look to you to help with
establishing the schema for the optional XML output.

Resistance schmesistance. Let's get 'er done.

-Crat
http://lpmuds.net

PS I haven't heard any objections to the -NOTES idea of post
http://www.mudbytes.net/index.php?a=topi...
so I'm thinking people are ok with it?

How is it possibly more "annoying" to generate the data in one format versus the other? It's just the tags and nesting that change. I don't see how the parsing is more "annoying" either. It's simpler to call a library API with a tag name and have it walk the data to retrieve the value(s), then to write my own code to do it. I'd like to hear technical arguments.

If, once all the attributes are finalized, XML is the selected markup, I'd be happy to generate the schema. Again though, XML is one of several options, and I'm happy to go with any one of them.

I'm kind of starting to think you're not listening to me. I've said over and over that I can write these libraries myself and provide them to people very quickly.

As for why parsing is difficult, well, as I said: my experience with XML parsers has been rather unpleasant. Maybe you can show just how simple it actually is and then we can all wander off and be happy forevermore.

Look, I'm not saying that the Tcl format is the end-all, be-all of markup languages. I am however saying that it is dirt simple and a very easy way to get started. You've said that we need fancier things in case we end up with trees. OK, fine – we can leave open that possibility using any number of methods. What you are suggesting is IMO not the easiest method.

If the target audience for this whole thing is, primarily, the mud listing sites…. why not ask them what format THEY would rather parse?

*blinks*

Seems like we have one such listing site right here, and there's a couple more that can probably be hit by rocks thrown from here… It just seems to me that it really doesn't matter how many mud admins might be willing to add support for something, if the listing sites themselves don't want to use it.

Then we're both guilty of it. Are you going to support and extend your libraries (for potentially several languages and platforms) indefinitely? Can you guarantee someone else will do so if you can't? That's the beauty of a widely adopted markup language, the tools are widely available and supported as well.

So if there is consensus that a standard markup is the right way to go, we then need to decide on one. At that point, I'm perfectly willing to dig into the available tools and prototype something. Besides the three markup languages mentioned already (i.e., XML, YAML, and SDL), are there others we should consider (e.g., JSON)?

There's no extending to be done for the parser. That's the whole point. It is designed to be simple and to get the job done with a minimum of fuss. Extension can be accomplished by setting a field in the protocol output specifying a new output format. Am I willing to fix bugs that are reported? Yes. Why? Because I expect there to be extremely few given the mind-boggling simplicity of the format. Am I willing to code something up for listings who can't figure out how to do it themselves? Yes, because the space of probable languages is very small. Unless you're saying that I'm not being truthful, I believe I have addressed your concerns. :wink:

Anyhow, I've made my case and don't really see the need to make it further – there's no sense playing any more verbal ping-pong here, wasting everybody's time. :shrug:

jesus, guys, you're over-engineering. step back for a minute. you're trying to develop something far, far more complex than what a Server Status Protocol calls for. FAR more complex.

I'd really recommend going with something entirely line-based, something that needs nothing more than basic string manipulation to parse, and something that doesn't require tons of data structures to deal with lists and maps and other crap. Remember that most MUD coders are hobbyist C programmers at best and are of vastly limited experience and skills, and I doubt are even capable of figuring out how to use a third-party C library much less implement a complex protocol themselves. Make it anything other than dead-simple and the protocol will be dead-on-arrival.

Look at what I originally posted as a suggestion. Essentially just a simplified version of the RFC822 header format. Parsing it is SUPER EASY!

I don't think a status protocol really needs lists or objects or anything that complex… but if you really think you need those, there's no reason that you need a full structured language for it. Heck, an array is just as easy as repeating the same key over and over:

ArrayKey: first value\r\n
ArrayKey: second value\r\n
ArrayKey: third value\r\n
ArrayKey: fourth value\r\n

Super simple. Even in C it takes only a handful of lines of code to parse a format like that.

You don't need to over think this stuff, people. You don't need to come up with a protocol that actually requires a whole freaking library to implement because its data protocol is too complex to parse correctly with a few dozen lines of code. XML and YAML and S-Expressions and TCL and Lua and JSON and all these other structured data formats are great when you actually need arbitrarily complex structured data, but there's absolutely no good reason to use them when your data is nothing more than list of key-value pairs. Those formats exist to solve the kinds of problems that you aren't having!

Related story: some years back when I was working as the AI developer for a never-released game about being an evil overlord running a secret underground and/or tropical-island lair (think Dungeon Keeper with a James Bond theme), we started working out the design for the player's super computer terminal. An obvious idea was to allow the player to spend money to upgrade to terminal to gain new features, like additional cameras (to spot super-spies… or slacking minions) and other useful tidbits. One of my co-developers came up with the idea of adding a very simple shellscript-like language that could be used for setting up some basic automation – nothing that a player actually HAS to use to play the game, but a nice touch for hacker-oriented players. Then someone suggested that the scripting language could also be upgraded with new versions of the terminal, adding additional features… like, say, you didn't get support for loops in the script language until you upgraded to Evil Terminal 2.0. Then some idiot (me) thought it might be neat to introduce occasional random bugs into different versions of the script engine that the user would have to work around or pay to have fixed, just like real proprietary software! Thankfully someone else called shenanigans at that point and we ended up scrapping the whole shellscript idea and replaced it with a batchfile-like hotkey system. Moral of the story? Even smart people who know better can still get caught up in the thrill of engineering a really cool and awesome architectural design that surpasses anything mankind has seen before; but the result just ends up being hard to use, a pain in the butt to implement, and offers nothing that the actual end-users ever wanted in the first place.

You guys are way off track with where you've taken this status protocol thing. This thread has degenerated into intellectual masturbation. Which is just like regular masturbation: it can be a lot of fun when you're bored, but all you end up with when you're finished is a big sticky mess. You don't want your status protocol to end up stuck in a sock buried at the bottom of the clothes hamper, do you?

There's like a big, massive, enormous echo in here, except that the echo is disagreeing with other things making the same point. :lol:

Good idea, if all else fails appeal to a random authority.

Not so random, unless you're planning to design something that no CURRENT mudlist will use, in the hopes that the "Field of Dreams" mindset will work for ya. OTOH, if you're designing this for your OWN mud client, which will interact with your OWN mud listing site, then by all means… have at you!

Those assets didn't eventually get sold to become "Evil Genius" did they? I loved that game. :)

Adding some sort of STATS command is pretty simple. Here's a ROM patch (untested)…

round about line 1560 something or so in comm.c…

case CON_GET_NAME:
	if ( argument[0] == '\0' )
	{
	    close_socket( d );
	    return;
	}
/* start patch for stats */
        if (!str_cmp(argument,"stats")) {
            display_status(d); 
            write_to_buffer(d,"Name: ",0);
            return;
        }    
/* end patch for stats */
	argument[0] = UPPER(argument[0]);
	if ( !check_parse_name( argument ) )
	{
	    write_to_buffer( d, "Illegal name, try another.\n\rName: ", 0 );
	    return;
	}

Then somewhere before nanny()…or after it if you're willing to type in a declaration…

static display_stats(d) 
{
    write_to_buffer( d, "CODEBASE Extremely Modified CircleMud\r\n", 0 );  
    write_to_buffer( d, "CREATED 1987\r\n", 0 );
    write_to_buffer( d, "LANGUAGE Pig Latin\r\n", 0 );
    write_to_buffer( d, "LOCATION My Basement\r\n", 0 );
    write_to_buffer( d, "NAME Shattered Dreamlike Dimensions of the Epic Abyss of Unquenched Darkness and Pain\r\n", 0 );
    write_to_buffer( d, "PLAYERS 5468\r\n", 0 );  /* This should be modified upward to keep your mud listed at the top! */      
    write_to_buffer( d, "UPTIME 150\r\n", 0 );    
    write_to_buffer( d, "\r\n", 0 );
}

This isn't an argument for it or against the elite Telnet mechanism.
This is just a patch for those who code like girls. ;-)

These are contradicting statements. Including a type of version field acknowledges that in the future there may be extensions to the MSSP data that indeed require parser updates. Again, can you guarantee you'll be available to do that for potentially several languages and platforms? The markup languages and tools already exist, so why are you insisting on going down this path? It's ok to recognize a good idea that didn't originate with yourself.

Also, there's no over-engineering here. Adopting a standard markup language, doesn't mean leveraging every capability. We're talking about an initially simple data set that can still be parsed with simple proprietary tools, but also ensuring that it can *easily* evolve if/when needed.