22 Mar, 2009, Les wrote in the 21st comment:
Votes: 0
David Haley said:
Since specs are "set in stone" – there are no versions! – any implementation knows what it's implementing. How could it possibly not have a list of commands it should be implementing?


elanthis' specs of the protocol and official subpackages are set in stone. It's important to keep in mind that the protocol is designed to allow arbitrary packages so mud servers or clients can have support some form of unique functionality and these mud server specific packages probably WILL change.

So just because my client has complete support for the org.foomud. package today doesn't mean that tomorrow the head coder at foomud doesn't add another command or two.
22 Mar, 2009, David Haley wrote in the 22nd comment:
Votes: 0
If you're talking about very specific MUD servers and clients developing new packages, it doesn't hugely matter what the package support system says because all kinds of other assumptions are being made.

If we're talking about standardizing the ability to ask if a package exists, it only makes sense to ask that question in the context of standard packages in the first place. If some package becomes a standard, and then people start throwing in new commands – and there is no package versioning – then arguably it is the new commands that are broken, not the fact that clients think they completely implement the package.

This is why I think packages should be versioned, if people want to play games with adding new stuff. Either you make a package publishing event be a "final" event, and new commands must go into a new package (Elanthis said this or something like it himself, at some point recently), or you allow for the possibility of new commands being thrown in, in which case the only sensible way to do that is via versioning.

By allowing for the package definition to change, it makes little sense to say that I support command package.cmd in the first place, because who knows – that command might have changed too. So I don't actually support what the server is asking for. I support what I thought was the package spec at the time I implemented it, based on what was published then…

Post #3 in this thread is what I'm going off of, in which Elanthis says pretty clearly that packages should not change. The argument I'm hearing in favor of some complicated command-by-command support reporting only makes sense in the context of packages changing. I don't care either way, but this half-way point just doesn't make sense. Either packages are set in stone once they're unleashed to the world, in which case it does make sense to have a list of required commands that will not change, or packages are not set in stone, in which case you need to version them so that everybody is on the same page.
22 Mar, 2009, Les wrote in the 23rd comment:
Votes: 0
David Haley said:
If you're talking about very specific MUD servers and clients developing new packages, it doesn't hugely matter what the package support system says because all kinds of other assumptions are being made.


It's not just me talking about it, the specification is talking about it. :smile:

David Haley said:
If we're talking about standardizing the ability to ask if a package exists, it only makes sense to ask that question in the context of standard packages in the first place. If some package becomes a standard, and then people start throwing in new commands – and there is no package versioning – then arguably it is the new commands that are broken, not the fact that clients think they completely implement the package.


It seems to me that foomud would be curious to know if the client supports org.foomud. even though it's not a standard package. And my point stands that foomud could very well be adding new commands all the time and it's not breaking anything because there is no spec for the foomud package.


David Haley said:
By allowing for the package definition to change, it makes little sense to say that I support command package.cmd in the first place, because who knows – that command might have changed too. So I don't actually support what the server is asking for. I support what I thought was the package spec at the time I implemented it, based on what was published then…


Yep this is a problem. At the very least it probably should be a SHOULD NOT in the standard (ie, you SHOULD NOT change the arguments and functionality of an existing command or some such).

David Haley said:
Post #3 in this thread is what I'm going off of, in which Elanthis says pretty clearly that packages should not change. The argument I'm hearing in favor of some complicated command-by-command support reporting only makes sense in the context of packages changing. I don't care either way, but this half-way point just doesn't make sense. Either packages are set in stone once they're unleashed to the world, in which case it does make sense to have a list of required commands that will not change, or packages are not set in stone, in which case you need to version them so that everybody is on the same page.


The half-way point is the distinction between the standard packages and any custom packages. Since you seem to disagree with the concept of the custom packages I'm not sure we'll be able to eye to eye on this one.
22 Mar, 2009, David Haley wrote in the 24th comment:
Votes: 0
I think there's some kind of miscommunication going on here. I'm not disagreeing with the idea of custom packages. I'm disagreeing that it's sensible to report that a command is supported or not when custom packages are not standardized.
Les said:
And my point stands that foomud could very well be adding new commands all the time and it's not breaking anything because there is no spec for the foomud package.

I don't understand how clients can reasonably be expected to implement a package that has no spec.
22 Mar, 2009, elanthis wrote in the 25th comment:
Votes: 0
The specs state which commands are part of the package. If you have the package, you have those commands, or you have a broken and incomplete implementation and the package should be disabled unless in debug/development mode. All the remote end needs to know is if you support the package.

For MUD-specific packages the assumption is that you either:

(a) are developing a specific client/server pair, so formalization is moot anyway

or

(b) you use sub-packages for new functionality, e.g. foomud.ui.*, foomud.bar.*, foomud.baz.*, etc. You then release specs for your sub-packages so other client authors can optionally implement them.

I argue that requiring a client to keep an **accurate** table of package commands including those that it doesn't support is no different than requiring a client to just implement the package properly in the first place.

Furthermore, I argue that getting a list of commands that a client does not support is no different than getting a list of commands it does not support, since elementary set theory allows you to figure out which commands are missing in that case. Thus the client implementation is simpler without losing any information.

I may be convinced to write up a stupid-simple IDL for ZMP and include those definitions in package specs, and then anyone who wants to bother using those could generate ZMP interfaces from them. I WILL NOT make that a mandatory part of the spec, though. That goes against one of ZMP's driving motivations: being incredibly simple to implement and to use.

ZMP does not include data serialization rules or anything else like that. It's SIMPLE. The original spec was actually called SMP (Simple MUD Protocol) before I decided that was too unlikely to get Google matches thanks to the other common meanings of SMP. :)

I honestly just dont' think it's going to be a big problem, either. Packages are small and simple. They are relatively unlikely to be partially implemented and then pushed into a client release, because a partial implementation of such small and simple packages would result in something totally unusable, something the client author wouldn't even have been able to test and get useful results from. If we had packages that included 30 complex commands, having a powerful versioned interface negotiation feature might be useful. I don't myself want to see a package like that. Even a GUI package should be developed with subpackages, so e.g. if a client only wants to implement basic dialogs, it only needs to support the gui.dialog. package, and a server can check for just that package.
22 Mar, 2009, David Haley wrote in the 26th comment:
Votes: 0
OK, so you're saying basically what I thought you were saying. Why are you bothering to return a list of commands in the first place, then, if the running assumptions are:
(a) not having them all means you're broken
(b) package specific client/server pairs are not meant to be formalized anyhow

If a list of supported commands is equivalent to a list of non-supported commands, then the assumption is that the full set of commands is indeed well established and unchanging.

So I still don't understand why we're operating on a command-level basis instead of just saying you support the package.
22 Mar, 2009, elanthis wrote in the 27th comment:
Votes: 0
The existing spec DOES just say you support an existing package. "zmp.check" "foopkg." is responded to with a simple "zmp.support" "foopkg." or a "zmp.no-support" "foopkg."

I don't think we need package checking at all since simply checking if a command IN a package is supposed is really the same thing without needing a separate chunk of code for package searching. You could just put all your supported commands into a hash table with callbacks (or a big array with callbacks for lazy C coders like me) and checking just requires seeing if the command is in there.

Others wants a little bit more information. Which I'm okay with, so long as we don't go overboard. I believe the updated spec should say something like "the implementation MAY optionally reply with all supported commands during a package check in zmp.check by listing each command as an additional parameter after the package identifier in the zmp.support response command." That keeps existing implementations legal and lets paranoid developers check for every support command easily. Not something I would've bothered with myself, but if enough other people want a simple extension like that, I'm game.
23 Mar, 2009, David Haley wrote in the 28th comment:
Votes: 0
OK, I might be mixing some things up due to a case of TLDR, but I had the impression that we were going to be listing supported commands in response to a package check request. I don't like the idea of it being optional to send commands back: that makes it confusing when one person says "I support the package" and the other says "I support the packages and these commands inside it".

What is the use case of that extra information? If checking for a single command is equivalent to checking for the whole package, why are we even talking about anything extra at all?

It only makes sense to me in the context of versioned packages, or packages with optional and required commands – and neither of those seem to be the case.
23 Mar, 2009, elanthis wrote in the 29th comment:
Votes: 0
Dunno. Tyche and Les, what are the use cases you're looking for with "list all commands in a package?" Just looking for completeness, or something I haven't thought of (which is quite likely, especially with as much Tanqueray as there is in me right now).

On another note, now that subwindow is (mostly) nailed down… what's next? I'd personally very much like a navigation-related package or something for clickable text.
23 Mar, 2009, Les wrote in the 30th comment:
Votes: 0
elanthis said:
Dunno. Tyche and Les, what are the use cases you're looking for with "list all commands in a package?"


For me, it's nothing more than convenience. subwindow has optional commands, namely set-input and input which a client shouldn't advertise if not supported. If the consensus is that it's better to just explicitly check for support of those commands then so be it and get rid of the package check langauge in the spec honestly.
23 Mar, 2009, David Haley wrote in the 31st comment:
Votes: 0
My view is that reporting package support should mean that you support all required commands in that package, and any additional commands you report are the optional commands. I just really am not seeing the point in reporting commands that you must implement anyhow – it's understood that since you support the package, you support the commands.

I'd like to talk about clickable text next, myself. Should be simple, I think? You'd need to define a list of label/command pairs, and then you'd need to specify the text that reveals that menu.
23 Mar, 2009, Mister wrote in the 32nd comment:
Votes: 0
For convenience, each release of a package could have a version. The client can then say "I support everything up to version 2, plus the following commands: yada-yada-yada". Also, a command itself may have different versions available (for example, a second version of window.open can accept a 'modal' parameter, unavailable in the first version, instead of introducing a new 'window.open_modal' command.)

So, to be compliant with version 1 of a package, you need full support for so-and-so commands; to be compliant with version 2, with so-and-so others.
23 Mar, 2009, elanthis wrote in the 33rd comment:
Votes: 0
We went over the versioning thing already. :) Versioning is beyond the scope of ZMP, and you can do versioning simply by making a second package with a version number tacked on. It doesn't bloat the implementation any more than adding in package schemas and versions because e.g. subwindow2.select can (assuming it has the same behavior in version 2) just use the exact same function/method as the version 1. e.g., a ZMP command array in C might be:

struct command_t {
char *name;
int argc;
zmp_command cb;
} commands = {
/* subwindow package; version 1 */
{ "subwindow.open", 4, subwindow_open },
{ "subwindow.select", 1, subwindow_select },

/* subwindow package; version 2 */
{ "subwindow2.open", 5, subwindow2_open },
{ "subwindow2.select", 1, subwindow_select },

{ 0, 0, 0 }
};


Notice how both versions of select used the same subwindow_select function. Only the open command (our example theoretical difference between versions) needed a second set of code written.

A Lua version of the same thing using a package constructor and metatables for package version inheritance might likewise be:

local subwindow = ZMP_Package{
_name = 'subwindow',
open = function(args)

end,
select = function(args)

end,

})

local subwindow2 = ZMP_Package{
_name = 'subwindow2',
_inherit = subwindow,
open = function(args)

end
});


Requires nothing extra on the part of ZMP, package checking, or anything else to pull off fully versioned package interfaces, and the tiny bit of registration code duplication is still smaller than it would be if the client had to register a full package version interface. It's win-win. :)
23 Mar, 2009, Wodan wrote in the 34th comment:
Votes: 0
David Haley said:
My view is that reporting package support should mean that you support all required commands in that package, and any additional commands you report are the optional commands. I just really am not seeing the point in reporting commands that you must implement anyhow – it's understood that since you support the package, you support the commands.

I'd like to talk about clickable text next, myself. Should be simple, I think? You'd need to define a list of label/command pairs, and then you'd need to specify the text that reveals that menu.


Could be really simple, although it would be nice if you could set up default sets of options where you can just fill in something like the object name (mxp can do this with entities) that makes it easy to have consistent options and saves you having to send the whole thing over every time.

I guess there could be a seperate macro package to handle such things (could be useful for more then just click on text menus after all), but that then needs to be able to include other zmp protocols in the resulting output, so it probably makes things harder to implement, any ideas?
23 Mar, 2009, elanthis wrote in the 35th comment:
Votes: 0
My opinion is to just not worry about "compressing" output or shortening it. If your server code is halfway intelligent you won't be needing to manually copy any ZMP commands/options around all over the place (just like you don't cut-n-paste code all over, you make reusable functions). The bandwidth concerns aren't really a concern, either, given that we essentially all have broadband and given that MCCP2 is easy to implement.
23 Mar, 2009, David Haley wrote in the 36th comment:
Votes: 0
I'm inclined to agree that we don't need protocol-level entity handling. Then again I wouldn't mind having it, other than protocol complexity. (You'd have to encode ZMP sequences inside other ZMP sequences, which means annoying things like escaping, etc.)
20.0/36