摘要

  • 1992 年 12 月，Lynx 已能启动远程程序、连接现有登录式服务，并把 University of Kansas 活动数据库的查询结果返回给读者。
  • 这些记录显示，它曾是校园信息与独立应用之间的桥梁；它们不能证明这种用法已广泛部署，也不能证明 Lynx 是首个连接服务的浏览器。

一个链接可以通向正在运行的程序

1992 年 12 月 8 日，Lou Montulli 解释 Lynx 如何连接大学里已经存在的资源。他举出的不是抽象设想，而是具体机制：客户端能通过 rexec 在远程主机运行程序、启动 inetd 应用，也能透明地建立 rlogin 会话。于是，用户点开链接后，目的地未必是另一份文档；它也可能是一个早已独立运行的服务。

图书馆系统是其中一个例子。Lynx 的链接可以让用户以链接中指定的账号登录远程图书馆主机。大学不必先把旧目录系统重做成 Web 应用，读者就能从校园信息菜单抵达它。另一个例子是“Events at KU”：用户选择校园菜单项后，Lynx 会在大学的 stat1 主机上调用数据库程序，向用户提问、查询数据库，再把结果送回客户端。Montulli 还说明，用户在打开该项目之前输入 =，便可以观察远程执行过程。

这样的细节让 Lynx 不再只是“能在终端上读网页”的浏览器。按照 Montulli 的描述，它也承担了启动入口的作用，而服务本身仍留在别的机器上。Telnet 和 TN3270 把这条路径延伸到面向终端的系统；Lynx 还能读取 Hytelnet 数据库。它并没有提供一个替代所有后台的新平台，而是把信息菜单和校园已经运行的工具连成一条可导航的路径。

浏览器之前，是校园信息系统

开发背景解释了这种设计为何实用。Michael Grobe 在后来的回顾中，将 Lynx 放在 University of Kansas 的 Academic Computing Services 校园信息系统项目中。他把自己、Charles Rezac 与 Montulli 列为主要开发者，同时提醒读者：开发过程合作密集，很难准确断定每项工作由谁在何时完成。因此，这段历史能支持的是一个持续演进的团队项目，而非由单人完成、日期清晰的发明故事。

当时，校园要让师生找到资源，并不需要立刻替换每个图书馆目录、活动数据库或终端服务。客户端可以缩短发现服务的路径，让各应用继续独立运行。这是根据 Montulli 描述作出的架构分析，并不表示账号、数据模型或安全边界已经统一。远程主机仍然提供程序，也仍由它决定是否准许访问。

便利也有边界。菜单把服务带到用户面前，但能否使用，仍取决于远程主机是否在线、账号规则、后端程序和网络路径。链接降低了寻找成本，却没有保证服务可用，也没有把运维责任交给 Lynx。校园获得了一个新入口，后台服务却没有因此变成可随处迁移的 Web 资源。

从校园入口走向 Web 客户端

这种变化是逐步发生的。1993 年 4 月 25 日，Montulli 宣布 Lynx 2.0.8 是一次重要的缺陷修复版本。他认为它已经稳定，但仍属于 beta，并希望在 6 月 1 日前发布非 beta 的正式版。这是当时提出的目标，不能当作实际发布日期。W3C 保存的一份产品记录随后列出 1994 年 4 月的 Lynx 2.3：它已是全屏超文本 Web 浏览器，可以用方向键和 Tab 操作。

更晚的 Lynx 用户指南说明了底层转变：后续版本接入了 World Wide Web 库，也能处理 HTML。随着 HTML 更普及，Lynx 自有格式逐渐退出。终端界面可以保留，变化的是文档和链接所依托的共同层。Lynx 不必放弃原有的键盘操作方式，也可以读取越来越多服务器采用的 Web 文档。

因此，Lynx 的历史包含两个相连的功能阶段。早期链接把校园入口接到既有应用；后来的客户端进入了由 HTML 文档和 WWW 服务器组成的更大空间。前者让安装好的系统变得可发现，后者则加入了更通用的信息层。现有证据没有说明所有校园都在同一时刻用后者取代前者。

记录能说明什么

Montulli 的同期邮件最具体：它列出技术机制，并描述University of Kansas的实际示例。Grobe 的回顾将开发放入团队协作背景，也明确提示归属和时间线的不确定性。1993 年的发布公告、W3C 的 1994 年产品记录和后来的用户指南，则勾勒出 Lynx 转向 Web 客户端、HTML 日益普及的过程。

这些材料共同支持一个克制的判断：在 Web 成为共同文档层之前，早期互联网界面已经能把人带到他们所依赖的既有系统。对当时的 Lynx 而言，链接的终点不一定是另一页；它也可以是一项仍在另一台主机上运行的服务。

来源