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.
Just they are backwards - the errors that each request can return should
be listed. You can ignore the ones that can be on any case.
> > 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?
A ref to invalid object is kinda weird. Also references to "why this
packet is wrong" are quite weird. Also you may want to reference what
the type of the message was that was incorrect (rather then the client
trying to dig through to find out which message was which reference).
> > 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?
Absolutely. The server has the information, it should send it back.
Plus it allows packets to be returned in any order (for future work -
most things in the protocol I don't see any reason for reply
guarantees). Also it allows the client to not have to maintain as much
info. The less state clients (and servers) have to handle the better.
> > 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.
It should be able to at least have the option to throw errors on this.
Malformed packets are malformed packets (and are generally an indication
of another error).
> 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?
Maintaining a protocol library?
I can't think of a reason NOT to add it. Once again the server has the
information, it should let the client know. It makes it a hell of a lot
easier when things are widely deployed and you get a bug report from
some guy in tzebeckistan saying he got error 44.8 (Frame (DeleteObject)
didn't contain valid object), rather then a 5 (Invalid Frame).
Remember debugging/maintaining is the bulk of coding time - not
development. And it makes it easier for both the client and server e.g.
"hold on a minute, the server says it's an invalid frame because I set
-1 for the length field, but the spec says -1 is allowed - it's a server
issue".
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
