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" ?