使用 ECMA 标准：Miguel de Icaza 访谈
Dare Obasanjo
2001 年 12 月

摘要：在本次访谈中，GNOME 和 Ximian 的创始人 Miguel de Icaza 讨论了 UNIX 组件、Bonobo、Mono 和 Microsoft .NET。
Dare Obasanjo：最近您一直忙于发布 Ximian（英文）的声明，宣布创建 Microsoft .NET 开发平台（英文）的开放源代码版本。此前，您为 GNOME（英文）和 Bonobo 所做的工作使您受到了世人的广泛关注。您能否简单概括一下从早期项目到 Mono（英文），您在免费软件开发方面所作的工作？
Miguel de Icaza：在过去的四年里，我一直从事 GNOME 项目的各个领域的工作，比如：GNOME 项目的组织、程序库和应用程序。此前，我从事 Linux 内核方面的工作：我用了很长时间研究 SPARC 端口；这之后研究了软件 RAID 和 Linux/SGI。之前，我编写了 Midnight Commander 文件管理器。
Dare Obasanjo：在您撰写的 Let's Make Unix Not Suck（英文）系列文章中，您曾提到由于缺乏可重复使用的代码致使 UNIX 的开发长期以来受到束缚，您特别强调了 Brad Cox（英文）的“软件集成电路”概念，指出软件构建主要基于组合可重复使用的组件，也就是要编写可以重复使用的代码。许多人反对您的观点，他们认为 UNIX 的建立基础，是通过使用管道连接较小程序的输出，来使用可重复使用的组件完成程序构建。您对这一反对观点有何看法？
Miguel de Icaza：是的，这个问题已经详细刊登出来了。这里提到的“管道”严格说不能作为完整的组件系统。它只是一种使用某些常用协议（例如行、字符、缓冲区等）处理信息的传输机制。而协议只拥有信息流。
详细内容都刊登在那篇文章（英文）中。[Dare - 请参阅“Unix Components: Small is Beautiful”。]
Dare Obasanjo：Bonobo 是您尝试以 CORBA 为基础来创建 UNIX 组件体系的产品，后来为何又转而开发 Mono 呢？
Miguel de Icaza：GNOME 项目的目标是补充 Unix 所缺少的技术，从而在桌面应用程序市场中更具竞争力。我们很早就意识到语言独立性的重要性，这也是 GNOME API 使用标准代码进行构建的原因。这种标准代码使得 API 可以被其他语言轻松打包。Unix 的大多数编程语言（例如 Perl、Python、Scheme、C++、Objective-C、Ada）都可以使用我们的 API。
后来，我们决定使用更好的方法来封装 API，于是就开始使用 CORBA 来定义组件的接口。我们还使用策略和一套标准 GNOME 接口对其进行补充，以便更轻松地创建可重复使用的、独立于语言的组件、控件和复合文档。这项技术就是今天的 Bonobo。C、Perl、Python 和 Java 都可以使用 Bonobo 的接口。
CORBA 擅长定义粗糙接口，而且大多数的 Bonobo 接口都是粗糙的。唯一的问题是 Bonobo/CORBA 接口都不善于定义小接口。例如，XML 分析 Bonobo/CORBA 组件可能没有 C API 有效。
以前我也论述过：

我对 .NET 的兴趣源于我们先前在 GNOME 项目中所做的努力，我们曾尝试使 .NET 能够完成以下目标：

• 可以向多种语言提供的 API
• 跨语言集成
• 基于合约/接口进行编程

当然除此以外，我一直钟爱各种有关 Java 的事情，只是不愿让 Java 组合有一丝缺陷。
我们尝试通过配备公共对象基类 (GtkObject) 在多种语言中提供 API，然后根据 API 约定和格式轻松地对 API 进行打包，以用于其自身的编程语言。我们还对 API 进行基于方案的定义，用它自由生成包装。鉴于多种原因，这个解决方案还是有些欠佳。
对 CORBA 进行的跨语言集成有些类似于 COM，但是要付出一些封送处理的代价。它可以很好地处理非进程组件，但是对于进程组件，情况就不那么美妙了：因为没有可用的 CORBA ABI，所以结果糟透了。对于这个问题，我不想多说什么。
此外，我们还遇到了程序库的扩大问题。大多数程序库都能非常准确地遵循代码惯例，但偶尔也会违反惯例，或者我们采用了其他人编写的程序库，却导致了程序库的混乱：虽然功能强大，但实现了多个编程模式。有时是不同的分配和所有权策略，有时又要处理 5 个不同种类的“ref/unref”行为（例如 CORBA 本地引用、关于未知对象的 CORBA 对象引用、对象包装的引用计数）。这使我们陷入了巨大的混乱之中。
当然，我们一直在努力修正这些问题，情况有了一定的改善 - 虽然 GNOME 2.x 平台的确解决了很多问题，但还是存在一些问题。
对我而言，.NET 就象是为 Win32 开发人员所做的升级：在处理 API 时他们遇到了同样的问题，因为 API 是多年前的设计，存在大量的不一致性。因此，在创建自己的应用程序时，我希望引进一些新的东西。
Dare Obasanjo：Bonobo 不太依赖于 COM 和 OLE2，这可以从 Bonobo 接口基于 Bonobo::Unknown 接口这一事实推出。该接口提供两项基本服务：对象生存期管理和对象功能搜索，并且只包含三种方法。

   module Bonobo {      interface Unknown {         void ref ();         void unref ();         Object query_interface (in string repoid);      };   };      

它们与 Microsoft 的 COM IUnknown 接口的三种方法非常相似。

HRESULT QueryInterface(REFIID riid, void **ppvObject);ULONG AddRef();ULONG Release();

.NET 似乎暗示了 COM 的终结这一事实，是否也意味着 Mono 将结束 Bonobo 呢？同样，考虑到 .NET 计划实现了半透明的 COM/.NET 互操作性（英文），Mono 和 Bonobo 是否也有类似的计划？
Miguel de Icaza：确实如此。Mono 必须与 GNOME 的 Bonobo 以外的大量系统进行交互操作。
Dare Obasanjo：许多人士声称 Microsoft .NET 平台只不过是 Java™ 平台的蹩脚的克隆。在这种情况下，Ximian 为什么决定不克隆或使用 Java 平台，而克隆 Microsoft .NET 平台？
Miguel de Icaza：因为 CLR 可以解决每天困扰我们的问题，而 Java VM 却不能，所以我们更喜欢 CLR。
Dare Obasanjo：Mono Rationale 页（英文）中指出 Microsoft .NET 策略提供了许多功能：

• .NET 开发平台，软件编写的新平台
• Web 服务
• Microsoft 服务器应用程序
• 使用新开发平台的新工具
• Hailstorm，作为以 Microsoft .NET Passport 为中心的单一登录系统，集成到 Microsoft Windows XP 中。

您还指出 Mono 仅仅是 .NET 开发平台的实现方案，那么 Ximian 是否计划实现 .NET 策略的其他部分？
Miguel de Icaza：目前尚未打算这样做。我们当前要开发的是：

• CLI 运行时，带有适用于 x86 CPU 的 JITer
• C# 编译器
• 类库

以上目标都需要外界的帮助。要知道这是一个庞大的工程，如果没人愿意无私地奉献他们的时间、技术和代码，那么我们将无法迅速地提供完整的产品。
我们这样做是出于自私的考虑：希望找到更好的方法开发我