I'm too lazy to piece together all kinds of different quotes, so I'll just reply based on what I remember reading:
Maximum length:
Awesome, no more limit. Maybe it will never be surpassed, but at least we are not stopping any possible use cases, nor complicating those cases where we indeed have 5k+1 characters to transmit.
Seperator byte:
My C implementation of the telnet protocol has zero issues with \0 bytes and allocates memory for telnet sub-negotiation sequences in decent steps thus reasonably optimizing for the smaller cases, but never limiting them. As I said before, if you want it, I can upload it somewhere. (I have optimized the telnet parser as a whole for speed as well so it could save some time in that sense.)
OnPluginTelnetOption callback:
Nick, you spoke of different callbacks for different protocols if I understood you right. I am talking about a single subnegotiation callback for all of the telnet options MUSHclient does not handle itself. Or even better, I'd love it if we could actually take up the choice for the primary negotiation ourselves for such cases. (Not to fall into a repeat affair with my mudserver codebase, but I also implemented a lua API for telnet sub-negotiation in there, keeping proper track of negotiation states and all that jazz.)
The protocol(s) itself:
Let's not fuss about what protocol we are using precisely. Not in the slightest because most plugins will still be quite mud specific, since all muds tend to differ in their gameplay mechanics.
I don't feel ZMP is the perfect solution, since from what I see it has considerable flaws. First of all, it keeps mentioning commands, and I don't see anywhere about plain notifications that do not require a response. I am also afraid it brings along too much of an urge to start doing all the scripted actions in subnegotiation by both mud coders and plugin writers alike, thus moving the actual 'playing' away from the primary channel which really already is a command-response kind of medium. Second, it has limitations on the content-bytes, no NUL bytes and so forth. The telnet protocol has no such limits, although it does ask IACs to be doubled as a form of escaping. Last of all, it seems to have packages and parameters, but beyond that it is all quite unstructured. Essentially there are only string parameters (unless I misunderstand). Nothing like arrays/lists/dictionaries unless you go and hack around a bit. In essence, really simple commands can easily be implemented, once you have anything with a bit more structure you'll be hacking away outside of the spec.
The new Lasher-Nick-Lua protocol also has its issues. Most of all that it IS quite Lua centric. I would prefer to see a straight table be submitted rather than the current different assignments into a setfenv()ed context, because this way, we can gently guide mud authors into writing more compatible messages with other languages. If you allow free-form Lua, you don't only need to worry about sandboxing and such (ok, that seems to be taken care of in your example) but also about the kind of commands you end up allowing. For example, I can imagine some weirdo scripters use for loops, while loops and the like to achieve what could be sent over in a simple table with said loops being done server side - all of which really complicates a Python implementation for example.
However, simply supporting a simplified table syntax would be simpler to implement in such languages. The only limitations that I can think of right away would be 1) no inline function declarations, and preferably 2) no mixing of lists and dictionaries in such tables as that is quite Lua unique. Then you'd get something like (extra whitespace for clarity, and way too specific inventory for the sake of being precise):
<IAC> <SB> <102> {
move=110,
poisoned=false,
mana=94,
maxhp=43,
hp=42,
tt="status",
combat=false,
level=2,
maxxp=7084,
gold=900,
xp=2116,
maxmove=110,
maxmana=94,
inventory = {
[1] = {
name = "book",
desc = "a magical book of Lua wizardry",
pages = {
[1] = "First page",
[2] = "Second page",
[3] = "Last page already."
}
},
[2] = {
name = "glasses",
desc = "some glasses"
}
},
dead=false
}
Which could also be loaded directly into a variable in Lua (_, blah = loadstring("return "..telopt_data) if I recall the syntax etc correctly). And for Python and other languages, writing a simple parser would be quite elementary (syntax is simple, C parser is available freely also, as are other languages I'm quite sure).
And in the case Lua isn't good enough, there's still other options. XML for the ones with suicidal tendencies (not my choice at all for live data like that, too verbose), but another choice might be JSON. My personal choice would likely be bencoded data (the format used in .torrent files). These last few are already established formats with the kinks worked out of them, and interpreting might be easier for clients due to existing libraries and such.
Either way, my point is... ZMP has flaws. The new LNL (Lasher-Nick-Lua) has flaws. XML has flaws. JSON has flaws, as does Python, VBScript, as well as bencoding. The proper protocol completely depends on the use case as well as the person implementing it.
Did I forget anything? :D Edit: Apparently yes, a small dozen new posts showed up while I was typing. *goes to read those now* |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top