Here's an unstructured list of some things that need to be addressed in a standards document. More will follow later.
1. Private extensions. Obviously the protocol is easy to extend just by adding new commands. To bring some order I suggest the following:
Standard commands are limited to use the characters [a-z_0-9] and must start with a character in [a-z], i.e. only lower case English letters, underscore, and digits, starting with a lower case letter.
Private commands are limited to the same characters plus hyphen and are suggested to be of the form "x-y" where "x" is a program specific prefix, e.g. gg for GNU Go and "y" is the rest of the command name. One example of a private command could be "gg-owl_attack".
I don't think we need to keep any official list of prefixes. These commands should be program-specific anyway.
2. Newline conventions That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point.
3. Case sensitivity Should the protocol in general be case sensitive or not?
4. Unknown command versus unimplemented command. I don't think it's useful to distinguish between unknown commands and unimplemented commands. Thus a program should respond with "?[id] unknown command" to everything it doesn't recognize or knows it can't handle. Currently GNU Go does like this:
| 1 fds | ?1 unknown command: 'fds'
I think we should skip everything following "unknown command".
/Gunnar
That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point.
Are there any other conventions besides the DOS and Unix ones?
It seems to me that this solution (discard CR) is best. But it means that applications have to be coded somewhat carefully.
Dan
- Newline conventions
That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point.
I agree that CR characters simply be ignored when received. That's how I've implemented my GTP. Sounds like we are in agreement with on this.
- Case sensitivity
Should the protocol in general be case sensitive or not?
The protocol should be case sensitive. If not, it would be impossible, for example to load SGF file ("loadsfg GAME1.sfg") on a Unix system since the Unix file systems are case sensitive.
-
Daniel Bump -
Gunnar Farneb�ck -
Phil