使用 ECMA 标准：Miguel de Icaza 访谈

答案：使用 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# 编译器 
类库 

以上目标都需要外界的帮助。要知道这是一个庞大的工程，如果没人愿意无私地奉献他们的时间、技术和代码，那么我们将无法迅速地提供完整的产品。
我们这样做是出于自私的考虑：希望找到更好的方法开发我们自己的 Linux 和 Unix 应用程序，而 CLI 正是我们所需要的。
也就是说，在服务和支持业务上，Ximian 将不吝提供支持，帮助 Mono 项目解决诸如移植到新平台、改善 JIT 引擎或者专注于 Mono 的某一特殊领域等问题。
但是除了这些，目前我们暂不考虑研究三项基本声明以外的项目。
Dare Obasanjo：现在有许多其他项目依靠免费平台实现 .NET 的其他部分，这似乎同 Mono 项目有点冲突。在第 7.2 节的 Portable.NET 常见问题（英文）中，好象是说在 dotGNU 邮件列表中禁止 Martin Coxall，是因为它们与 Mono 项目发生了冲突。对此您有何看法？
Miguel de Icaza：我没有留意 DotGNU 邮件列表中禁止 Martin 的详细情况。Usenet 和 Internet 的邮件列表都体现了它们各自的特点，我认为这也是 Internet 上常见的现象之一吧。不过，出现这种问题确实令人难过。
Mono 和 .NET 只有细微的差别：我们尽可能使用 C# 等高级语言编写程序，而使用其他语言编写可重复使用的软件片段。目前，Portable.NET 是使用 C 语言编写的。
Dare Obasanjo：媒体对于 Ximian 和 Microsoft 的关系的报道也大相径庭，有的报道似乎暗示在保护 .NET 和 GPL 的许可协议之间可能存在许可问题。还有的报道说，Microsoft 内部有些人对 Mono 极为关注。那么，目前 Ximian 与 Microsoft 的关系到底如何呢？应采取何种措施确保当 Microsoft 的许可协议转为有限制时，在 .NET 问题上 Mono 才不会违反 Microsoft 的许可协议？
Miguel de Icaza：好，第一点，我们是从头编写每样东西的。
另外，在专利方面，我们也尽量避免侵权问题的发生。也就是说，我们目前使用的方法都是别人以前使用过的方法。而且对于 Mono，我们尚未做出太细致的工作或者取得很有效的成果，相反我们差得还很远，目前只是

上一个：.NET Framework正式版已知Bug列表
下一个：COM, COM+ and .NET 的区别(转)