27 Feb, 2009, kiasyn wrote in the 182nd comment:
I would like to point out that MUDBytes already runs a crawler that connects via telnet to check connectivity.
27 Feb, 2009, David Haley wrote in the 183rd comment:
A lot of crawlers do that – I think getting the information over telnet is quite viable for that reason. The idea of putting it into RDF onto a website isn't bad, but not all MUDs have a website, and besides, I think it takes more know-how to set something like that up. Plus, we'd need to put in more work on defining the schema and all that. The current world view of a series of key/val pairs is dead simple.
27 Feb, 2009, Scandum wrote in the 184th comment:
The biggest problem here is a bunch of dudes confusing everyone by their insistence on using "status" or whatever instead of IAC DO MSSP and bla:bli\r\nbla:bli\r\n instead of IAC SB MSSP MSSP_VAR "bla" MSSP_VAL "bli" MSSP_VAR "bla" MSSP_VAL "bli" IAC SE.
27 Feb, 2009, David Haley wrote in the 185th comment:
Scandum, what was the problem there exactly?
27 Feb, 2009, Grimble wrote in the 186th comment:
kiasyn said:
I would like to point out that MUDBytes already runs a crawler that connects via telnet to check connectivity.
It's more likely they're opening a TCP connection via a socket library for their scripting language of choice. If the connection succeeds, they've verified connectivity. The telnet protocol, which rides over said socket, never comes into play.
Edit: It's worth noting that it's no simpler for the crawler to implement MSSP via telnet than it is scraping off the data resulting from a well-known command string. It is simpler for the server… rather the people maintaining those servers, who run the gamut with respect to software skills, in that adding a command and debugging the human-readable output is easier for them. I believe this is why Cratylus first brought up the idea.
27 Feb, 2009, David Haley wrote in the 187th comment:
What is the useful distinction w.r.t. MudBytes's crawler's ability to talk to the MUDs?
27 Feb, 2009, elanthis wrote in the 188th comment:
David Haley said:
A lot of crawlers do that – I think getting the information over telnet is quite viable for that reason. The idea of putting it into RDF onto a website isn't bad, but not all MUDs have a website, and besides, I think it takes more know-how to set something like that up. Plus, we'd need to put in more work on defining the schema and all that. The current world view of a series of key/val pairs is dead simple.
I postulate that if a MUD coder cannot set up a simple text document on a website, he cannot implement MSSP, in any incarnation. I'm also interested to know which MUDs that the general populace actually cares about lacks any form of web site here in 2009 (so that I can point and laugh).
I'm not saying that MSSP is entirely a bad idea. I'm only saying that if you need anything more than very simple data, there's no reason to invent an entire complex proprietary MUD protocol for it when there are already technologies around that do exactly what is needed using existing tools that are far better suited to complex structured data.
27 Feb, 2009, Cratylus wrote in the 189th comment:
elanthis said:
I postulate that…
Let's keep it clean, please. Kids read these threads.
elanthis said:
…if a MUD coder cannot set up a simple text document on a website, he cannot implement MSSP…
I do like your idea, but it seems to bump up against the concept of this
being a "status" protocol. Sure a static web page is brain dead simple
to set up, but keeping the data on it live would involve one more notch
up on the know-what-you're-doing scale, and would be, IMO, equivalent
to the notch required for spitting out status strings at the login screen
upon request.
-Crat
http://lpmuds.net
27 Feb, 2009, David Haley wrote in the 190th comment:
I agree that if you need complex data, something along the lines of what you're talking about is useful. At the current stage of key/val pairs, I think the text dump is sufficient.
For what it's worth, I'm not sure how much sense it really makes to be talking about structured data. Structure implies ontology. If the idea is for a crawler to talk to many MUDs of many types, this implies that we have some kind of meaningful ontology for all relevant types. That is a very difficult task that I don't think any of us want to do or have the time for. Actually, I'm not convinced it's even useful.
Maybe you could have one ontology per family of MUDs, but this approach has issues of its own.
For this reason I strongly prefer a very simple data universe, and there's not much point using a structured format if the underlying data isn't really structured to begin with.
For what it's worth, I'm not sure how much sense it really makes to be talking about structured data. Structure implies ontology. If the idea is for a crawler to talk to many MUDs of many types, this implies that we have some kind of meaningful ontology for all relevant types. That is a very difficult task that I don't think any of us want to do or have the time for. Actually, I'm not convinced it's even useful.
Maybe you could have one ontology per family of MUDs, but this approach has issues of its own.
For this reason I strongly prefer a very simple data universe, and there's not much point using a structured format if the underlying data isn't really structured to begin with.
28 Feb, 2009, kiasyn wrote in the 191st comment:
Grimble said:
It's more likely they're opening a TCP connection via a socket library for their scripting language of choice. If the connection succeeds, they've verified connectivity. The telnet protocol, which rides over said socket, never comes into play.
Edit: It's worth noting that it's no simpler for the crawler to implement MSSP via telnet than it is scraping off the data resulting from a well-known command string. It is simpler for the server… rather the people maintaining those servers, who run the gamut with respect to software skills, in that adding a command and debugging the human-readable output is easier for them. I believe this is why Cratylus first brought up the idea.
kiasyn said:
I would like to point out that MUDBytes already runs a crawler that connects via telnet to check connectivity.
It's more likely they're opening a TCP connection via a socket library for their scripting language of choice. If the connection succeeds, they've verified connectivity. The telnet protocol, which rides over said socket, never comes into play.
Edit: It's worth noting that it's no simpler for the crawler to implement MSSP via telnet than it is scraping off the data resulting from a well-known command string. It is simpler for the server… rather the people maintaining those servers, who run the gamut with respect to software skills, in that adding a command and debugging the human-readable output is easier for them. I believe this is why Cratylus first brought up the idea.
the crawler is actually written in c++ :P
but im happy to do whatever needed to support this.
but guys stop complicating it.
28 Feb, 2009, Scandum wrote in the 192nd comment:
kiasyn said:
the crawler is actually written in c++ :P
but im happy to do whatever needed to support this.
but guys stop complicating it.
but im happy to do whatever needed to support this.
but guys stop complicating it.
The MSSP protocol is available in the first post of the other thread, right now I doubt I'll change the negotiation. I can send you some beta code for a C parser if you're interested.
28 Feb, 2009, elanthis wrote in the 193rd comment:
Cratylus said:
I do like your idea, but it seems to bump up against the concept of this
being a "status" protocol. Sure a static web page is brain dead simple
to set up, but keeping the data on it live would involve one more notch
up on the know-what-you're-doing scale, and would be, IMO, equivalent
to the notch required for spitting out status strings at the login screen
upon request.
being a "status" protocol. Sure a static web page is brain dead simple
to set up, but keeping the data on it live would involve one more notch
up on the know-what-you're-doing scale, and would be, IMO, equivalent
to the notch required for spitting out status strings at the login screen
upon request.
The actual intended use-case of this is for crawlers. The crawlers are intended to use this to display MUD list and rankings. The crawlers are not going to be reconnecting to every MUD on every page load in order to get up-to-date information. Actual real-time statistics thus aren't really all that useful, because the actual sites showing the data are just going to be caching it anyway.
I see no problem with having the setup being limited to showing "maximum number of players on within the last 24 hours" instead of "number of players on this very second." Regenerating an XML/HTML file every 5 minutes is still going to result in updating the information more often than any crawler is actually going to be looking at it.
28 Feb, 2009, Scandum wrote in the 194th comment:
A serious mudstat site could connect 8 to 12 times a day and report the amount of players with 3 hour intervals.
28 Feb, 2009, quixadhal wrote in the 195th comment:
Scandum said:
A serious mudstat site could connect 8 to 12 times a day and report the amount of players with 3 hour intervals.
I'll agree with Scandum here. While you could provide an additional field for max players today, the player count field should be the number of players currently online. That lets people who might use aggregate tools construct their own averages, maximums, etc, as they see fit (and so long as the mud owner doesn't mind getting hit every X minutes).
It might BE a good idea to have a max players field, just because the crawler might decide to pick bad times for a particular mud's player base activity. It would have to be date-stamped though…. else you'd get into the "Well, it was today's total in MY timezone" argument.
28 Feb, 2009, elanthis wrote in the 196th comment:
"Last 24 hours" has no timezone.
28 Feb, 2009, David Haley wrote in the 197th comment:
How many people actually care about this, versus being interested in giving their opinion? Just curious, no value judgment. I think we're very rapidly reaching the point where talking isn't getting anywhere anymore – in the other thread, people are starting to make the same observations that were made pages and pages ago here.
28 Feb, 2009, Cratylus wrote in the 198th comment:
David Haley said:
How many people actually care about this, versus being interested in giving their opinion? Just curious, no value judgment. I think we're very rapidly reaching the point where talking isn't getting anywhere anymore – in the other thread, people are starting to make the same observations that were made pages and pages ago here.
I do care, actually…part of where I've been coming from has involved me
thinking about how to implement it on the codebase I maintain, and how to
to get other people to adopt it. I would be doing this because the code I'd
generate would be LPC, and I'd try to lend my LPC expertise in coding that
to others less inclined or able to do it themselves.
Having said that, if the telnet deal is dropped and a web-based deal is
established, that pretty much nullifies my direct participation except as
a "suggester", since a web specification requires no particular skill
or expertise to implement…just the ability to read.
Elanthis said:
Actual real-time statistics thus aren't really all that useful,
That may be true, but that wasn't the point of the proposal, as I understood
it. Whether the value for it was low or not, I've been thinking of it as a
status querying protocol. Moving it to a "basically static, rarely updated"
stance makes it a Mud Server Listing Protocol, and changes things a bit
psychologically, since I'd been thinking of it also in terms of a tool
to capture *actual* status of a mud, not what the admins put on their
webpage 2 years ago and forgot to update.
-Crat
http://lpmuds.net
28 Feb, 2009, Rendelven wrote in the 199th comment:
I think that some realtime statistics can be rather useful, some if not all have already been mentioned:
The number of players currently online, maybe a max players?
The uptime of the MUD.
What about an option that allows the MUD to tell the crawler how
often to update? A min-max value?
The number of players currently online, maybe a max players?
The uptime of the MUD.
What about an option that allows the MUD to tell the crawler how
often to update? A min-max value?
28 Feb, 2009, elanthis wrote in the 200th comment:
Quote
What about an option that allows the MUD to tell the crawler how
often to update? A min-max value?
often to update? A min-max value?
An EXPIRES variable would be an excellent idea. Same way Web crawlers work, actually. I would also suggest a DATE variable noting the local time according to the server.
Both should require the timestamp in either RFC 3339 format (my preference) or in RFC 2822 format.
Random Picks
It was an example, and only an example. The point I was making is let's take a step back and validate the proposed set of variables to date, which you are asking for as well. The intersection of data that is shared by a plurality of MUD servers may well be very small, but we may also find there is indeed a case for nested data because it's the is best way to model what we're interested in.
It looks to be a case of NIH.