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

On 28/10/2022 03:46, Cameron Kaiser wrote:
> This doesn't help for the non-menu case but this is still very helpful to me
> running a bot. Pruning dead selectors on still existing sites in the Veronica-2
> database is currently its worst implemented feature and often requires me doing
> manual cleanup or sometimes simply blowing away an entire site and reindexing
> it from scratch. This would give me a programmatic way to remove tree "limbs"
> at the menu level and save a lot of headache.

This made me wondering. What problem would we be trying to solve here 
exactly? Such "normalized error codes in port field of errors" would 
only be useful to bots. But then, we cannot expect all gopher servers in 
the world to follow this convention, meaning that bots will still need 
to implement some guessing logic.

In my own bots, I simply look at the entries in the menu, and if it 
contains at least one error item I discard the page as being unworthy 
(either does not exists, or is otherwise broken). Seems robust enough.

The bigger problem I have is to figure out when a text file (or any 
other non-menu file for the matter) does not exists, and sadly the 
approach we are discussing here won't help with these cases.

Another huge problem I have is selectors that were a menu and become a 
text file  overnight, or vice-versa.

In the discussed context, maybe a saner convention would be simply: "if 
the file or menu does not exist, then a well-behaved server SHOULD close 
the connection right away, without sending back anything at all - 
ideally shutting the connection using a TCP RST if possible" ?

Mateusz