I'm going to split this into a number of emails. Will make future
thread tracking easier.
> Fail Frame
>
> Nash mentioned that he finds the current fail frame too limiting. Maybe
> adding
> a list of GRS (General Reference System) references might help?
In particular for sequences. Invalid objects in the middle of a
sequence require you to track which object was invalid in a list.
Eg a
<GetObj><22><33><92><21>
Returns:
<seq><Obj22><Obj33><Fail><Obj21>
It's rather silly to have to track which failed in a client, when the
server has enough information to be able to send it. Also note that a
human readable error message is not really necessary for such a failure.
(ie, it is very easy for the client to handle this in code, without any
sort of error message).
I wonder if there needs to be a different type of fail frame for such
things (after all a string is pretty useless).
Frame: SeqDoesNotExist
uint32_t ObjID that failed
Personally I like to consider that a client should be able to avoid
'Fails' in most cases. Else a there needs to a clear distinction
between soft fails (ObjId that has been deleted - caused by turn
generation or similar) and hard fails (The message you sent doesn't make
sense).
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
