To evolve or not to evolve
Hi all,
Jame's recent question about TLS made me think. Not about TLS itself,
because that's a topic that has been discussed many times in the past,
but about a more general subject.
We are a community of tinkerers, consequently we feel the urge to fiddle
with bits and pieces whenever possible. This is obvious if we look at
the currently existing gopher nodes: they are full of neat scripts and
toys that display cool things. But what should be our approach to the
protocol itself? Over the years, some "de facto standards" appeared: a
couple of new item types here and there, some tolerance for missing
"terminating dots" in menus or text files, flexibility over used
charsets, and more.
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?
Mateusz
gopher://gopher.viste.fr
Reply to: