On Thu, 2007-03-15 at 10:53 +1100, Brett Nash wrote: > Hello All, > > One thing I'd really like to see added is better documentation on > failure messages - in particular for each command what type of failures > we can expect. Some errors would be universal, but some need to listed > that they can occur.
I've added a few descriptions of what I think the error messages should be used for. They are probably a bit wishy-washy so feel free to pick on them. > I think it may be nice to add an extra info field for each failure too. > General reference may do it. But may be overkill, and may not cover all > cases. It may be overkill, can you think of any cases it may not handle? > For instance in the sequence example an object ID would be nice to know > which one caused the failure. For example, if I send a GetObjectByIDs(10, 11, 12) I would get back Sequence(3) Object(10) Fail Object(12) I'm assuming you want the failure frame to say I was originally a request for 11 so you don't need to keep track of what you actually requested? > For invalid frames it would be nice to know why it was invalid, too > long packet, too short packet, malformed packet, illegal message type, > incorrect protocol version (or subversion) etc. "too long packet" shouldn't actually be an error. The server/client should just ignore the bit at the end it doesn't understand. The added failure types don't go as far as adding "malformed packet", "illegal message type", etc. Can you think of any reason to add these apart from when debuging a protocol library? > Regards, > nash > > P.S. As I speak a commit to the protocol4 document covered some of these > concerns. Not most of them :) Tim Ansell _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
