"Phil Garcia" PhilippGarcia@Home.com writes:
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com To: gtp@lists.lysator.liu.se Sent: Sunday, August 19, 2001 9:55 PM Subject: RE: [gtp] GTP Specification-Draft
Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id
What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
I agree, these numbers seem to be useless in a requst/response type of protocol. Unless there is a really good reason for keeping them, I'm all for removing them. Existing GTP developers please speak up.
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
We could do what the existing internet protocols do (smtp, nntp, ...), and have both a 3-digit error code, followed by explanatory text.
dd
On Mon, Aug 20, 2001 at 11:57:25AM +0100, Dave Denholm wrote:
"Phil Garcia" PhilippGarcia@Home.com writes:
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com
[..]
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
We could do what the existing internet protocols do (smtp, nntp, ...), and have both a 3-digit error code, followed by explanatory text.
(I haven't found the original proposal either, so I'm responding only to the comments.)
I think it's a good idea to have a mechanism for extensions which is smart enough to allow a standard "not implemented" response.
However, I'm not sure whether error messages need to be standardized. (I'm not considering "I don't have your [optional] extension" to be an error condition.) Protocols like SMTP and HTTP (dunno NNTP) which do the standard error condition thing have a need for nontrivial error recovery because they are used by long-running daemons (e.g. mailers talking to mailers, and proxies talking to proxies) without human operators present at either end, and they need to do smart things about long-term state (like queued mail messages and cached documents) in the presence of failures (like servers or network links going down). But in a Go protocol which is just used for tournaments, IGS-style client/server stuff, regression testing, and whizzy UIs, there might be no such need to make interesting error-recovery decisions without human input. Therefore, it might be sufficient always to handle errors by terminating the session and printing out or logging the error text.
In my experience, it can be very tedious to maintain software (and specifications for software) which does nontrivial error recovery based on error codes. Writing it the first time is OK, but when something changes, you end up with lots of work for large committees and then lots of annoying proof-reading and tweaking of every error-handling switch statement; or else the committee isn't gung-ho enough to keep up, and you end up with various ugly kludges because your error conditions evolve away from the standard. Using OO inheritance for error conditions helps reduce the pain at maintenance time, but it still takes a significant amount of space and work in the specification (as in e.g. Java and Common Lisp). If you could get away without any fancy error recovery at all, it might be a good thing.
However, I'm not sure whether error messages need to be standardized.
I agree 100% with this.
By the way, "not_implemented" is not an error message, it's a legitimate response that does NOT indicated an error. It's a way of saying, "I have not implemented that command."
There has been a tremendous amount of resistance to adding even very simple commands, the main argument being that it's extra work to implement more than the very most basic 4 or 5 commands. Having a set of standardized error codes for each command is certainly not very compatible with this philosophy.
Don
From: William Harold Newman william.newman@airmail.net References: 001701c12934$5cc4e3d0$0100a8c0@fastgo 001001c12940$7fc112d0$0b01a8c0@pghome km1ym7vw16.fsf@insignia.com Mime-Version: 1.0 X-Mailer: Mutt 1.0.1i Sender: gtp-admin@lists.lysator.liu.se Errors-To: gtp-admin@lists.lysator.liu.se X-BeenThere: gtp@lists.lysator.liu.se X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: mailto:gtp-request@lists.lysator.liu.se?subject=help List-Post: mailto:gtp@lists.lysator.liu.se List-Subscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=subscribe List-Id: Discussion about the computer-go protocol GTP. <gtp.lists.lysator.liu.se> List-Unsubscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=unsubscribe List-Archive: http://lists.lysator.liu.se/pipermail/gtp/ Date: Mon, 20 Aug 2001 08:44:40 -0500 Content-Type: text/plain; charset=us-ascii Content-Length: 3351
On Mon, Aug 20, 2001 at 11:57:25AM +0100, Dave Denholm wrote:
"Phil Garcia" PhilippGarcia@Home.com writes:
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com
[..]
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
We could do what the existing internet protocols do (smtp, nntp, ...), and have both a 3-digit error code, followed by explanatory text.
(I haven't found the original proposal either, so I'm responding only to the comments.)
I think it's a good idea to have a mechanism for extensions which is smart enough to allow a standard "not implemented" response.
However, I'm not sure whether error messages need to be standardized. (I'm not considering "I don't have your [optional] extension" to be an error condition.) Protocols like SMTP and HTTP (dunno NNTP) which do the standard error condition thing have a need for nontrivial error recovery because they are used by long-running daemons (e.g. mailers talking to mailers, and proxies talking to proxies) without human operators present at either end, and they need to do smart things about long-term state (like queued mail messages and cached documents) in the presence of failures (like servers or network links going down). But in a Go protocol which is just used for tournaments, IGS-style client/server stuff, regression testing, and whizzy UIs, there might be no such need to make interesting error-recovery decisions without human input. Therefore, it might be sufficient always to handle errors by terminating the session and printing out or logging the error text.
In my experience, it can be very tedious to maintain software (and specifications for software) which does nontrivial error recovery based on error codes. Writing it the first time is OK, but when something changes, you end up with lots of work for large committees and then lots of annoying proof-reading and tweaking of every error-handling switch statement; or else the committee isn't gung-ho enough to keep up, and you end up with various ugly kludges because your error conditions evolve away from the standard. Using OO inheritance for error conditions helps reduce the pain at maintenance time, but it still takes a significant amount of space and work in the specification (as in e.g. Java and Common Lisp). If you could get away without any fancy error recovery at all, it might be a good thing.
-- William Harold Newman william.newman@airmail.net "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-
Dave Denholm -
Don Dailey -
William Harold Newman