Nick Gammon said: Anyway, what is the justification for throwing away the IAC x?
The spec says pretty clearly that IAC means "interpret the next byte as a command". My reading is that, if you don't know what the command is, you just ignore the command; you wouldn't blow up, or treat it as the 'IAC' byte. After all, if you tell me: "David: do the task", I know to do the task, but if you say: "David: do the flipperflop foo", I'll have no idea what you are talking about and will ignore you. :P (Well, actually, I'd ask you what you meant, but that's the nice thing about being able to actually communicate...)
Nick Gammon said: Let's assume every system has some flaws, and at this stage I am trying to reduce any in my proposed system (e.g. message limits, handling of subnegotiation), and offer up simplicity and ease of use as an argument for it.
I don't think it's all that simple if you're not working in Lua on the receiving end. For example, you also now have the problem I mentioned to Twisol regarding PPI, where a Lua list-table looks like a map to Python, even though it should be creating it as a list object.
I think it's very simple and easy to use if you're working in Lua on the receiving end.
I think it makes it more difficult to standardize messages across MUDs, because that would require another layer of standardization on top of this. (ZMP provides that layer explicitly with the package mechanism, although you still obviously have to write a package spec.)
Of course, I'm not necessarily convinced that it's realistic to expect some kind of large, cross-MUD standardization effort. So, eh. Maybe this doesn't matter.
Somebody brought up the problem of a too-loosely defined protocol data format: "assignments that Lua can handle". Does this mean that you can assign arbitrary expressions, including function calls? What if you sent:
<IAC> <SB> tt="foo";hp=math.pow(2,2) <IAC><SE>
what is the expected value of hp: "math.pow(2,2)" or 4?
IMO this is a pretty serious issue.
To be clear, my statement is not that this new protocol is not good. It's that we're doing something that might already have been done. We could come up with many variations of protocols that are nice etc., repeating what's been done. (For example, we could have sent Python code, not Lua code.)
Actually I kind of like the protocol because using Lua really does make things nice and easy (if you're using Lua). 'course, I have no objection to forcing Lua. :-) |