Re: To evolve or not to evolve
It was thus said that the Great Mateusz Viste once stated:
>
> These are all things that were not part of RFC 1436, yet they are useful
> and work relatively well. So, where's the limit?
>
> My subjective opinion is that any improvement over RFC 1436 is fine, as
> long as it answers a practical need without degrading the service for
> legacy implementations. For example: introducing a new itemtype for PDF
> files is harmless, because old clients are unable to process PDFs
> anyway, so it makes no difference for them whether the file is
> advertised as "d", "9" or something else.
> Same for CAPS support: an old client won't look for it, so no harm done.
>
> What's your stance on this?
The one thing I do miss from HTTP is the ability to redirect a request.
So, as an experiment, I added the ability to mark a selector as having been
moved, using the standard gopher error mechanism. So, if you attempt to
retreive the selector '/Phlog:' on my server [1], you'll get:
3Permanent redirect Phlog: gopher.conman.org 70
This came about because a gopher page I regularly referenced suddenly
disappeared, and it took me a while to find that the page had moved to a new
selector.
I also added the ability to mark pages as gone. I don't have an actual
example of that, but it would look like:
3Gone foobar gopher.conman.org 70
-spc
[1] gopher://gopher.conman.org/
Reply to: