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

阅读数:1277 2019 年 11 月 13 日 11:14

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

这篇文章主要是想阐述一下, 针对 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

评论

发布