这篇文章主要是想阐述一下, 针对Gopher, 我有哪些经验及实践，尤其是那些我不是很喜欢的，以及那些因为要遵循惯例而受制约的事情等等。

第一个出场的是“i”项目类型，即information（信息）类的内容。该类型有别于其它Gopher类型，它并不代表一种资源，仅仅用于显示，这就使得，Gopher菜单交互在规定的特殊场景下变得复杂。令人尴尬的是，Gopher面对这个问题只字不提，虽然说有人想处理这些错误也不是什么坏事，不过他们认为这件事情毫无意义。正是这种没有约束的滥用，使得系统层面的约束就显得尤为重要；我曾见过一个完全由项目类型构成的文件，而sans却是单个的，这就是滥用的极致。这样做不仅易读性差，而且浪费了信息传递和处理的时间。我第一次看到这个的时候感到极其困惑，由此更是生出厌恶之感。此类型令人震撼的用法是那些空白，因此为了阐明原因，仅用于表示控件。

与这种不喜欢相关的，是我一直遵循的惯例，非常希望我的Gopher能够保持。如果我写文章时需要其他的资源，像图片或者程序文件，甚至一篇文章的不同版本，文章会以菜单的形式呈现，包括他的每一个条目，也包括文章本身。最近比较不错的一个例子就是我的2019-06-23的这篇文章，他是以程序和元数据作为主线，后面是文章的几个不同的版本。让我觉得惊奇的是，当我告诉别人这种方法时，遇到了一些很有意思的评述，我本以为这是一个很基本的方法，但是别人却夸我很聪明，能想到这一点。其实在我最开始学习Gopher的时候就马上想到了，并考虑着如何写到我的文章中等等。

其次就是“URL:” 约定Gopher选择器引用HTML文件。这个并不像“i”类那么糟糕，因为对于那些不是特别懂它的客户来说，他们会有明确的行为规范，并且相互之间能够形成解耦。然而，这依然很差。不难想象，一个菜单项是否按照某种约定，链接到两个不同的资源，任何一种选择都各有利弊。此外，它完全与标准文档相反，那些文档中特别说明了选择器字符串不应该具有任何特殊含义；因此，如果希望它在客户端正常运行，便会禁止使用以“url:”开头的选择器。有人觉得这并不是什么问题，如果可以接受的话，它可以被更长久地使用下去。人们会很轻易地认为，以不同内容开始的选择器都是有特殊含义的；这就是问题所在。

我的建议是，如果没有充分理由，一般来说尽量避免链接到HTML文件上。我链接纯粹是因为这篇文章的其他几个版本已经完成了。尽管有些不规范，但使用“h”项目类型也是相当不错的，因为可以预见它的行为是合乎逻辑的，虽然我很想知道有多少客户端准备接收文本传输或者直接的HTML文件方式。由于HTML下载后可验证，并具有指定的项目类型，所以我将其视为不做任何修改的直接下载，就跟“i”项目类型一样。与此相关的是，由于Gopher URL规范的缘故，人们认为Gopher选择器是以“/”开头的，并且对于Gopher选择器使用的是换行符，而不是回车和换行符对，这两个换行符同样很差，他们太常见了，服务器应该对此进行谴责。

第三个是“caps.txt”选择器协议。拥有可用于某些事情的恒定资源，无疑是有积极意义的，这类似于主菜单的空选择器，但我觉得这种协议缺乏美感。首先是选择器本身；为什么它应该用一个通用的文件命名来表示；一个好的选择器应该具备一个能力，就是可以避免不必要的缩写，并且不会使用任何特定通信存储的方法。其次，它是一种由POSIX标记的格式，因此显得很难看；它包含注释工具；gopher菜单不支持注释；它是一种“key=value”格式；Gopher没有这种格式；它仅仅是一种从POSIX到Gopher的特殊格式的转换。除此之外，它还有一些不必要的工具，可以将选择器作为POSIX文件名进行详细的处理；这是完全没有必要的；如果一个Gopher hole理员配合地提供“caps.txt”资源，那么就可以轻松地优化选择器和其他类似的服务器，相反，就会很困难。它还有其他琐碎的细节。总之，我觉得这违背了Gopher的精神。我见过的另一个选择是“robots.txt”，反对它的理由是，所有WWW的谬论都不应该出现在Gopher中。

原文链接：

http://verisimilitudes.net/2019-07-07

创作场景

针对 Gopher 代码，我有一些小建议