Would it be better to add an UNREPORT MSDP command instead of automatically clearing all previous reports whenever a REPORT command is used?

The way REPORT is currently supposed to remove variables on each call is kind of inelegant to implement.

UNREPORT would allow adding and removing small variable sets from the report list without having to resend everything.

It would, in fact I meant to bring this up and forgot about it. My snippet actually doesn't clear previous reports, because this would make it difficult to handle the generic gauge variables.

In practice I've yet to find a situation where I needed to stop reporting. However I can envision future scenarios where it might be desired, so it'd be nice to include in the specification. It would also be nice to have a way to UNREPORT everything, so that you could clear the slate and then send a fresh REPORT.

I'm having a hard time picturing where someone would want to stop reporting as well. It'd be possible to add an exception to unreport everything, but I fear it'd be ultimately hackish, and never used.

The client side MSDP implementations I've seen pretty much know which variables they want to have reported, so it'd be just as easy to REPORT as to UNREPORT.

So I'm leaning toward simplicity.

Well I'm thinking for more customisable interfaces, for example a "score" window that updates to reflect your attributes, position, etc - if the player chooses to close that window, there's no need to continue reporting those variables. It's not going to do any real harm if you continue reporting them, but it does mean you'll be sending data the client no longer wants.


Muds with account systems (where the client doesn't need to reconnect in order to switch characters) might wish to track different information for each character, such as "blood" for a vampire, "rage" for a werewolf, etc. I think in such cases it would make life easier if the client could simply clear the old REPORT variables and request a new set.


It's still early days, we've not yet seen any really clever client-side scripts. Right now everyone seems to request the variables at the start and leave it at that. When clients start requesting new variables on-the-fly it's going to become more difficult to keep track of them.

One option is introducing a RESET command that takes VARIABLES, REPORTABLE_VARIABLES, and CONFIGURABLE_VARIABLES as an argument. The generic guideline would be that the variable states should be reset to their defaults.

RESET : VARIABLES would reset all variables, while RESET : REPORTABLE_VARIABLES should take care of REPORT related resets.

If the idea is just to clear the old REPORT variables, then having RESET work on anything other than REPORTABLE_VARIABLES wouldn't make sense.

You could just say that the "UNREPORT" command can also take "REPORTABLE_VARIABLES" as a valid argument. Or perhaps "ALL", or even a "*" wildcard. I wouldn't want people doing "REPORT ALL" though - I could see some people doing it out of laziness, and I'd rather encourage them to only request what they need. But from a consistency perspective it seems a bit strange to offer it to UNREPORT and not REPORT.

I wonder if it might be worth including a REPORTED_VARIABLES variable, that includes all the variables you've asked the mud to REPORT? Then you could use "LIST REPORTED_VARIABLES" to view them (handy when debugging your scripts) and "UNREPORT REPORTED_VARIABLES" to clear them, and obviously "REPORT REPORTED_VARIABLES" wouldn't make sense so you'd avoid that problem as well.

RESET : VARIABLES would reset everything, which might be useful in some cases, or with future extensions. It's the equivalent of starting with a clean slate.

I'm not a huge fan of using more than one input type for commands, as "REPORTABLE_VARIABLES" is not a variable, but a list (for lack of a better term). Another advantage of using RESET is that functionality can be negotiated with LIST COMMANDS, which would return RESET as a valid command, while negotiating the dual usage of wildcards or lists is not, and it'd probably be tedious to figure out a clean way to do so.

I'm also not in support of allowing wildcards as it wouldn't allow logarithmic lookups, and instead of a single result you'd allow for multiple matches, which is tricky to handle in C as you can't return a table.

I do like the idea of a REPORTED_VARIABLES list. I'll add that to the spec.

I'm really wary regarding allowing both lists and variables as arguments, I'd rather have LIST and RESET accept lists, and REPORT, UNREPORT, and SEND accept variables. This should allow very clean implementations, as simplicity seems to be the strongest selling point of MSDP.

Being a little further along with my implementation I've noticed how the VARIABLES list can be confusing. Currently there are four types of variables, COMMANDS, LISTS, REPORTABLE, and CONFIGURABLE.

Would it save some confusion to drop the VARIABLES list from the specification? I could see clients requesting the VARIABLES list when they really want the REPORTABLE_VARIABLES list, and servers being inconsistent in whether they include COMMANDS and LISTS when the VARIABLES list is requested, especially as this may be tricky for servers that don't treat commands or lists as variables. Not to mention that someone will argue that commands and lists aren't variables, though lists are variables client side.


I'm still on the fence about RESET vs UNREPORT REPORTED_VARIABLES. The consistency implications of doing the latter are pretty big, as besides REPORT REPORTABLE_VARIABLES one would expect SEND REPORTED_VARIABLES to work as well. I also don't think it'd do the clarity of the specification much good to describe variable input types.

RESET seems like the cleanest option, though I haven't given the handling of resetting configurable variables much thought.

I've updated the specification with the following changes:

1) No longer need to unreport previously reported variables when a REPORT command is received.
2) The VARIABLES list has been removed.
3) The REPORTED_VARIABLES list has been added.
4) RESET command added that takes a list argument, and can be used to reset any given list.

Hopefully that'll be all the protocol drama for 2011.

http://tintin.sourceforge.net/msdp

Please put it back, it's needed! Not all variables are REPORTABLE or CONFIGURABLE, and with the latest specification it's no longer possible to find out which such variables the mud offers.

My mud, and all those muds using my snippet, use VARIABLES to list every variable that can be requested via SEND. So no, that doesn't include COMMANDS or LISTS, as you can't SEND those.

By the way my snippet also includes the concept of "write-once" CONFIGURABLE_VARIABLES, although there is no way for the client to differentiate them from regular CONFIGURABLE_VARIABLES. If you try to set them after they've already been set, the mud just ignores your request. This is used for things like client name, so that if the client developer wishes to use MSDP instead of TTYPE they can, and the player can't just write over the top of it with an MSDP script.

I figured variables can be made reportable even if they never update, but that may not be the greatest idea. Would it make sense to introduce a STATIC_VARIABLES list and define VARIABLES as containing configurable, reportable, and static variables?


I probably won't implement that for MTH as I expect most clients to only implement an interface to save MSDP data into a native data table.

Some muds may not wish to implement REPORT for all of their variables (even variables which update). Other muds may not implement REPORT at all - perhaps they want to keep their MSDP implementation as simple as possible and just stick with SEND.


I would probably use the term SENDABLE_VARIABLES for consistency. The question is, are there any situations in which you'd want a variable that you can REPORT or CONFIGURE but not SEND? Unless there are, VARIABLES and SENDABLE_VARIABLES would always be the same.

Perhaps the specification could mention that VARIABLES includes all variables that you can SEND, REPORT or CONFIGURE, and mention that implementations may include SENDABLE_VARIABLES if it would differ from VARIABLES?

Out of curiosity I just checked which variables were different, but as far as I can tell gw2 reports the same variables for 'variables' and 'reportable_variables'.

While at it, a list name better suited than STATIC_VARIABLES might be ENVIRONMENT_VARIABLES. I can't really think of variable types other than configurable, reportable, and predefined environment variables.

My main worry with supporting VARIABLES is that it increases potential buffer overflow problems. I think with an ENVIRONMENT_VARIABLES list most should be covered.

You're right, the same with my snippet, but that's just my implementation - it may not be true for others. It may not even be true for GW2 in the future. I've got a load of "unofficial" variables accessable via a GW2SEND command which I'd like to integrate properly, but I doubt I'll make them all REPORTABLE.


I'd say the CONFIGURABLE_VARIABLES are more like environment variables.

I propose sticking with VARIABLES, REPORTABLE_VARIABLES and CONFIGURABLE_VARIABLES, as that's what everyone is currently using. If you want a separate list for SEND I'd prefer SENDABLE_VARIABLES.

I guess SENDABLE_VARIABLES will work as a catch all for the SEND command. That would be consistent with the REPORT command.

As far as I can tell this will cover all the bases for the current command interface. I'm still on the fence about the VARIABLES list.

I went ahead and added SENDABLE_VARIABLES to the specification.