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/