Re: itype 3 as generic status Re: To evolve or not to evolve

On 27/10/2022 11:14, Matt Owen wrote:
> Can we be sure though that there aren't any legacy clients out there that do this:
> 
> parts=split(line,"\t")
> if parts[0]=="3" {
>   'do something
> }

As I understand it, the proposition is to use a generic "error" (type 3) 
itemtype, only applying some convention to what its description looks 
like, so some "smart" clients or bots could try interpreting it 
automatically.

This changes nothing for legacy clients: these would just display the 
error string.

Cameron made a valid point about languages, though. I think that the 
description string should be left 100% dedicated to human texts to not 
pollute the user's visual space. Perhaps could we abuse the "port" field 
of the error item line to provide a 16-bit error code? This field is 
currently useless anyway for error lines.

Such approach would prevent using the "3" line for redirecting the user 
somewhere else, but maybe it's for the best, because a "3" line is not 
supposed to be selectable in the first place, so a proper "1" or "0" 
line must be present anyway for non-smart clients so the user can click 
on it.

The convention could be "if first line of menu is a 3 error with code 
301 in port field then client might want to follow the first selectable 
line of the menu".

In the same spirit: "if first line of menu is a 3 error with code 404 in 
port field then it means the selector does not exist".

Mateusz