Freigeben über

Verwenden der ECMA-Standards: Ein Interview mit Miguel de Icaza

  • Artikel

 

Dare Obasanjo

Dezember 2001

Zusammenfassung: In diesem Interview spricht Miguel de Icaza, gründer von GNOME und Ximian, über UNIX-Komponenten, Bonobo, Mono und Microsoft .NET. (6 gedruckte Seiten)

Dare Obasanjo: Sie waren kürzlich in der Presse, weil Ximian angekündigt hat, eine Open Source Implementierung der Microsoft .NET-Entwicklungsplattform zu erstellen. Vor dem letzten Furor waren Sie für die Arbeit, die Sie mit GNOME und Bonobo geleistet haben, bemerkenswert. Können Sie einen kurzen Überblick über Ihr Engagement für freie Software von Ihren früheren Projekten bis hin zu Mono geben?

Miguel de Icaza: Ich arbeite seit vier Jahren am GNOME-Projekt in verschiedenen Bereichen: organization davon, Bibliotheken und Anwendungen. Davor habe ich am Linux-Kernel gearbeitet, ich habe lange zeit am SPARC-Port gearbeitet, dann am Software-Raid und einige am Linux/SGI-Aufwand. Zuvor hatte ich den Midnight Commander-Datei-Manager geschrieben.

Dare Obasanjo: In Ihrer Let's Make Unix Not Suck-Reihe Erwähnung Sie, dass die UNIX-Entwicklung lange Zeit durch eine fehlende Codewiederverwendung behindert wurde. Sie Erwähnung insbesondere das Konzept der integrierten Softwareschaltungen von Brad Cox, bei dem Software in erster Linie durch die Kombination wiederverwendbarer Komponenten erstellt wird, als Vision, wie Code wiederverwendet werden soll. Viele haben Ihren Argumenten entgegengehalten, indem sie angeben, dass UNIX auf dem Konzept basiert, wiederverwendbare Komponenten zum Erstellen von Programmen zu verwenden, indem die Ausgabe kleinerer Programme mit Pipes verbunden wird. Wie stehen Sie zu diesem Gegenargument?

Miguel de Icaza: Nun, das Papier behandelt diese Frage im Detail. Eine "Pipe" ist kaum ein vollständiges Komponentensystem. Es handelt sich um einen Transportmechanismus, der mit einigen bekannten Protokollen (Zeilen, Zeichen, Puffer) verwendet wird, um Informationen zu verarbeiten. Das Protokoll verfügt nur über einen Informationsfluss.

Details sind auf dem Papier. [Dare – Überprüfen Sie den Abschnitt mit dem Titel "Unix-Komponenten: Klein ist schön".

Dare Obasanjo: Bonobo war Ihr Versuch, eine UNIX-Komponentenarchitektur mit CORBA als zugrunde liegender Basis zu erstellen. Was sind die Gründe, warum Sie sich stattdessen für Mono entschieden haben?

Miguel de Icaza: Das Ziel des GNOME-Projekts war es, fehlende Technologien auf Unix zu bringen und es auf dem aktuellen Markt für Desktopanwendungen wettbewerbsfähig zu machen. Wir haben auch früh erkannt, dass die Unabhängigkeit der Sprache wichtig war, und deshalb wurden GNOME-APIs mit einem Standard codiert, der es ermöglichte, die APIs problemlos für andere Sprachen umschließen zu können. Unsere APIs sind für die meisten Programmiersprachen unter Unix verfügbar (Perl, Python, Scheme, C++, Objective-C, Ada).

Später haben wir uns entschieden, bessere Methoden für die Kapselung unserer APIs zu verwenden, und wir begannen, CORBA zum Definieren von Schnittstellen für Komponenten zu verwenden. Wir ergänzten sie mit Richtlinien und einer Reihe von GNOME-Standardschnittstellen, um problemlos wiederverwendbare, sprachunabhängige Komponenten, Steuerelemente und zusammengesetzte Dokumente zu erstellen. Diese Technologie wird als Bonobo bezeichnet. Schnittstellen zu Bonobo sind für C, Perl, Python und Java vorhanden.

CORBA ist gut, wenn Sie grobe Schnittstellen definieren, und die meisten Bonobo-Schnittstellen sind grob. Das einzige Problem besteht darin, dass Bonobo/CORBA-Schnittstellen für kleine Schnittstellen nicht geeignet sind. Beispielsweise wäre eine XML-Analyse von Bonobo/CORBA-Komponenten im Vergleich zu einer C-API ineffizient.

Ich habe auch irgendwann geschrieben:

Mein Interesse an .NET ergibt sich aus den Versuchen, die wir bereits im GNOME-Projekt unternommen haben, um einige der Dinge zu erreichen, die .NET tut:

  • APIs, die für mehrere Sprachen verfügbar gemacht werden
  • Sprachübergreifende Integration
  • Vertrags-/Schnittstellenbasierte Programmierung

Außerdem habe ich immer verschiedene Dinge an Java geliebt. Ich habe einfach nicht die Java-Kombination geliebt, die Sie geben oder nehmen sollten.

Wir haben versucht, APIs für viele Sprachen verfügbar zu machen, indem wir über eine gemeinsame Objektbasis (GtkObject) verfügen und dann einem API-Vertrag und einem Format folgen, mit dem andere die APIs problemlos für ihre Programmiersprache umschließen können. Wir verfügen sogar über eine schemabasierte Definition der API, die verwendet wird, um Wrapper on the Fly zu generieren. Diese Lösung ist aus vielen Gründen suboptimiert.

Die sprachübergreifende Integration, die wir mit CORBA gemacht haben, ähnlich wie COM, aber mit einer verhängten Marshalling-Strafe. Es funktioniert ziemlich gut für Nicht-inProc-Komponenten. Aber für inProc-Komponenten ist die Geschichte ziemlich schlecht: Da es keine CORBA-ABI gab, die wir verwenden konnten, ist das Ergebnis so schrecklich, dass ich keine Worte habe, um es zu beschreiben.

Zusätzlich zu diesem Problem haben wir eine Vermehrung von Bibliotheken. Die meisten folgen ziemlich genau unseren Codierungskonventionen. Ab und zu würden sie entweder nicht oder wir eine Bibliothek übernehmen, die von jemand anderem geschrieben wurde. Dies führte zu einer Mischung aus Bibliotheken, die, obwohl im Ergebnis leistungsfähig, mehrere Programmiermodelle, manchmal unterschiedliche Zuordnungs- und Besitzrichtlinien implementieren und nach einer Weile mit 5 verschiedenen Arten von "ref/unref"-Verhalten zu tun haben (LOKALE CORBA-Verweise, CORBA-Objektverweise auf unbekannten Objekten, Verweisanzahl auf Objekt wrappern), und dies wurde zu einem riesigen Chaos.

Wir haben natürlich versucht, all diese Probleme zu beheben, und die Dinge sehen besser aus (die GNOME 2.x-Plattform löst viele dieser Probleme, aber trotzdem).

.NET schien mir ein Upgrade für Win32-Entwickler zu sein: Sie hatten die gleichen Probleme wie bei APIs, die über viele Jahre entwickelt wurden, sehr viel Inkonsistenz. Daher möchte ich einige dieser neuen "frischen Luft" zur Verfügung haben, um meine eigenen Anwendungen zu erstellen.

Dare Obasanjo: Bonobo basiert leicht auf COM und OLE2, wie aus der Tatsache zu entnehmen ist, dass Bonobo-Schnittstellen alle auf der Bonobo::Unknown-Schnittstelle basieren, die zwei grundlegende Dienste bereitstellt: Verwaltung der Objektlebensdauer und Objektfunktionalitätsermittlung und enthält nur drei Methoden:

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

die der COM-IUnknown-Schnittstelle von Microsoft mit den folgenden Methoden sehr ähnlich ist

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

Bedeutet die Tatsache, dass .NET zu impliziert scheint, dass das Ende von COM nahe ist, dass Mono das Ende von Bonobo bedeuten wird? Wenn man bedenkt, dass .NET eine halbtransparente COM/.NET-Interoperabilität plant, gibt es einen ähnlichen Plan für Mono und Bonobo?

Miguel de Icaza: Definitiv. Mono muss mit einer Reihe von Systemen zusammenarbeiten, einschließlich Bonobo auf GNOME.

Dare Obasanjo: Mehrere Parteien haben behauptet, dass die Microsoft NET-Plattform ein schlechter Klon der Java-Plattform™ ist. Wenn dies der Fall ist, warum hat Ximian nicht entschieden, die Java-Plattform zu klonen oder zu verwenden, anstatt die Microsoft .NET-Plattform zu klonen?

Miguel de Icaza: Wir waren an der CLR interessiert, weil sie ein Problem löst, mit dem wir jeden Tag konfrontiert sind. Die Java-VM hat dieses Problem nicht gelöst.

Dare Obasanjo: Auf der Seite Mono Rationale wird darauf hingewiesen, dass die Microsoft .NET-Strategie viele Anstrengungen umfasst, einschließlich:

  • Die .NET-Entwicklungsplattform, eine neue Plattform zum Schreiben von Software
  • Webdienste
  • Microsoft Server-Anwendungen
  • Neue Tools, die die neue Entwicklungsplattform verwenden
  • Hailstorm, das zentrale System für einmaliges Anmelden von Microsoft .NET Passport, das in Microsoft Windows XP integriert wird.

Und Sie weisen darauf hin, dass Mono lediglich eine Implementierung der .NET-Entwicklungsplattform ist. Gibt es einen Plan von Ximian, andere Teile der .NET-Strategie zu implementieren?

Miguel de Icaza: Nicht an diesem Punkt. Wir haben uns verpflichtet, zurzeit folgendes zu entwickeln:

  • Eine CLI-Laufzeit mit einem JITer für x86-CPUs
  • Ein C#-Compiler
  • Eine Klassenbibliothek

Alle oben genannten Mitwirkenden mit Hilfe von externen Mitwirkenden. Sie müssen verstehen, dass dies ein großes Unterfangen ist und dass wir ohne die verschiedenen Menschen, die ihre Zeit, Ihr Fachwissen und ihren Code für das Projekt gespendet haben, nicht einmal eine Chance hätten, bald ein komplettes Produkt zu liefern.

Wir tun dies aus egoistischen Gründen: Wir wollen eine bessere Möglichkeit, Linux- und Unix-Anwendungen selbst zu entwickeln, und wir sehen die CLI als solche Sache.

Allerdings würde Ximian, der im Dienstleistungs- und Supportgeschäft tätig ist, nichts dagegen haben, seine Bemühungen zu erweitern, damit das Mono-Projekt andere Dinge wie die Portierung auf neue Plattformen, die Verbesserung der JIT-Engine oder die Konzentration auf einen bestimmten Bereich von Mono anstrebt.

Aber abgesehen davon haben wir zum gegenwärtigen Zeitpunkt keine Pläne, über die drei grundlegenden Ankündigungen hinauszugehen, die wir gemacht haben.

Dare Obasanjo: Es gibt eine Reihe anderer Projekte, die andere Teile von .NET auf kostenlosen Plattformen implementieren, die anscheinend Reibungen mit dem Mono-Projekt haben. Abschnitt 7.2 der Portable.NET FAQ scheint darauf hinzuweisen, dass sie mit dem Mono-Projekt in Konflikt geraten sind, ebenso wie das Verbot von Martin Coxall aus der dotGNU-Mailingliste. Was denken Sie dazu?

Miguel de Icaza: Ich habe nicht auf die tatsächlichen Details des Verbots von Martin aus den DotGNU-Mailinglisten geachtet. Usenet- und Internet-Mailinglisten sind eine eigene Kultur und ich denke, dies ist nur eine weitere instance dessen, was normalerweise im Internet geschieht. Es ist definitiv traurig.

Der Fokus von Mono und .NET ist etwas anders: Wir schreiben so viel wie möglich in einer allgemeinen Sprache wie C# und schreiben wiederverwendbare Softwareteile daraus. Portable.NET wird in C geschrieben.

Dare Obasanjo: Es gab widersprüchliche Berichte über Ximians Beziehung zu Microsoft. Auf der einen Seite gibt es Berichte, die darauf hindeuten, dass es möglicherweise Lizenzprobleme zwischen der Lizenz gibt, die .NET und die GPL steuert. Andererseits gibt es einen Hinweis darauf, dass einige innerhalb von Microsoft von Mono begeistert sind. Was genau ist die aktuelle Beziehung von Ximian zu Microsoft und was wird getan, um sicherzustellen, dass Mono nicht gegen die Microsoft-Lizenzen auf .NET verstößt, wenn sie sich als restriktiv erweisen?

Miguel de Icaza: Nun, zum einen schreiben wir alles von Grund auf neu.

Wir versuchen, bei Patenten auf der sicheren Seite zu bleiben. Das bedeutet, dass wir Dinge auf eine Weise implementieren, die in der Vergangenheit verwendet wurde und wir in Mono noch nicht sehr aufwendige oder effiziente Dinge tun. Davon sind wir noch sehr weit entfernt. Aber nur mit vorhandenen Technologien und Techniken.

Dare Obasanjo: Es wurde darauf hingewiesen, dass Sun Java mindestens zweimal aus Standardprozessen zurückgezogen hat. Wird das Mono-Projekt fortgesetzt, wenn .NET aus irgendeinem Grund nicht mehr ein offener Standard ist?

Miguel de Icaza: Das Upgrade auf unserer Entwicklungsplattform hat unabhängig davon, ob es sich um einen Standard handelt oder nicht, einen Wert. Die Tatsache, dass Microsoft seine Spezifikationen einer Aufsichtsbehörde vorgelegt hat, hat geholfen, da Personen, die von diesen Problemen wissen, das Problem untersucht haben und Probleme für die Interoperabilität ermitteln können.

Dare Obasanjo: Ähnlich verhält es sich, wenn die Vorhersage von Dan Kusnetzky wahr wird und Microsoft die .NET-APIs in Zukunft ändert? Wird das Mono-Projekt aufholen oder wird es zu einer inkompatiblen Implementierung von .NET auf UNIX-Plattformen?

Miguel de Icaza: Microsoft ist bemerkenswert gut darin, seine APIs abwärtskompatibel zu halten (und dies ist einer der Gründe, warum ich denke, dass sie als Plattformanbieter so viel Erfolg hatten). Daher denke ich, dass dies kein Problem wäre.

Selbst wenn dies ein Problem war, ist es immer möglich, mehrere Implementierungen derselben APIs zu verwenden und die richtige zu verwenden, indem Sie zur Laufzeit die richtige "Assembly" auswählen. Assemblys sind eine neue Methode für den Umgang mit Softwarepaketen, und die Dateien, die Teil einer Assembly sind, können kryptografisch überprüft und ihre APIs programmgesteuert auf Kompatibilität getestet werden.   [Dare — Sehen Sie sich die Beschreibung der Assemblys aus dem .NET Framework Glossar an.]

Selbst wenn sie von der ursprünglichen Version abweichen, wäre es also möglich, Assemblys bereitzustellen, die abwärtskompatibel sind (das können wir beide tun: Microsoft und uns selbst).

Dare Obasanjo: Beim Betrachten der Mono-Klasse status Seite ist mir aufgefallen, dass eine große Anzahl von .NET-Klassenbibliotheken nicht in Mono implementiert wird, z. B. Windows Forms, ADO.NET, Webdienste, XML-Schemas, Reflektion und eine Reihe anderer. Dies bedeutet, dass es sehr wahrscheinlich ist, dass Anwendungen, die für .NET geschrieben wurden, nach der endgültigen Veröffentlichung von Mono und .NET nicht portierbar sind. Gibt es einen Plan, dies in Zukunft zu korrigieren, oder ist die Erstellung einer portablen .NET-Plattform kein Ziel des Mono-Projekts? Was sind die kurz- und langfristigen Ziele des Mono-Projekts?

Miguel de Icaza: Die status Webseite spiegelt die Klassen wider, an denen Benutzer "angefordert" haben, um zu arbeiten. Die status Webseite ist nur eine Möglichkeit, zu sagen: "Hey, ich arbeite an dieser Klasse ab diesem Datum", um Codeduplizierung zu vermeiden. Wenn jemand sein Interesse an der Arbeit an etwas registriert und nach einiger Zeit nichts tut, können wir die Klasse zurückfordern.

Wir befinden uns in den sehr frühen Phasen des Projekts, sodass Sie sehen, dass mehr Arbeit an den grundlegenden Klassen als an den Endbenutzerklassen ausgeführt wird.

Ich hatte nicht einmal erwartet, dass so viele großartige und talentierte Programmierer so früh am Projekt mitwirken. Meine ursprüngliche Vorhersage ist, dass wir die ersten drei Monate alleine in der Öffentlichkeit ohne externe Beiträge hacken würden, aber ich habe mich als falsch erwiesen.

Sie müssen erkennen, dass die Ziele des Mono-Projekts nicht nur die Ziele von Ximian sind. Ximian hat eine Reihe von Zielen, aber jeder Mitwirkender zu dem Projekt hat seine eigenen Ziele: einige Leute möchten lernen, einige Leute arbeiten gerne an C#, andere möchten vollständige .NET-Kompatibilität unter Linux, einige Möchten Sprachunabhängigkeit, einige Leute möchten Code optimieren, einige Leute mögen Low-Level-Programmierung und andere möchten mit Microsoft konkurrieren, einige Leute mögen die Funktionsweise von .NET-Diensten.

Die Richtung des Projekts wird also von denen gesteuert, die dazu beitragen. Viele Menschen sind sehr an einer kompatiblen .NET-Implementierung für Nicht-Windows-Plattformen interessiert und tragen dazu bei, diese Lücken zu schließen.

Dare Obasanjo: Wie plant Ximian, für die Kosten für die Entwicklung von Mono zu bezahlen, insbesondere nach dem Scheitern einer Reihe von unternehmen, die kürzlich mit Venture finanzierten, freien Software-basierten Unternehmen wie Indrema, Eazel und Great Bridge, und der Tatsache, dass ein beträchtlicher Prozentsatz der verbleibenden freien Software-basierten Unternehmen auf dem Seil liegt? Wie plant Ximian, mit freier Software im Allgemeinen und Mono im Besonderen Geld zu verdienen?

Miguel de Icaza: Ximian bietet Support und Dienste. Wir haben kürzlich einige unserer Dienstleistungen angekündigt, und weitere Produkte und Dienstleistungen sind seit einer weilen Pipeline und werden in den nächsten sechs Monaten angekündigt.

Die kürzlich angekündigten sind:

  • Red Carpet Express: Ein Abonnementdienst für diejenigen, die einen zuverlässigen, schnellen Zugang zu den Red Carpet-Servern wünschen.
  • Red Carpet Corporate Connect: Wir haben unsere Red Carpet Updater-Technologie geändert, damit Benutzer Netzwerke von Linux-Arbeitsstationen einfach verwalten und benutzerdefinierte Softwarepakete bereitstellen und verwalten können.
  • Support und Dienstleistungen für den GNOME Desktop und Evolution: Unsere neuesten Boxprodukte sind unsere Art, Support-Dienstleistungen für die verschiedenen Produkte zu verkaufen, die wir liefern.

Wir bieten auch professionelle Dienstleistungen und Unterstützung für Menschen, die freie softwarebasierte Lösungen integrieren.

Der besondere Fall von Mono ist interessant. Wir arbeiten an Mono, um unsere Entwicklungskosten zu senken. Es wurde ein sehr schöner Grundstein gelegt und der ECMA vorgelegt. Nun entwickeln wir mit Hilfe anderer Interessierter, die die Leistungsfähigkeit der Software erkennen, die Mono-Laufzeit und Entwicklungstools, um unsere Produktivität zu verbessern.

Tatsächlich ist das Team, das bei Ximian an Mono arbeitet, das in der Vergangenheit dem Rest des Unternehmens infrastrukturelle Hilfe zur Verfügung gestellt hat.

Dare Obasanjo: Es ist wahrscheinlich in einigen Ecken wenig bekannt, dass Sie einst mit Microsoft interviewt haben, um am SPARC-Port des Internet-Explorer zu arbeiten. Haben Sie sich in Anbetracht der Auswirkungen, die Sie seitdem auf die Freie-Software-Community hatten, jemals gefragt, wie Ihr Leben gewesen wäre, wenn Sie Ein Microsoft-Mitarbeiter geworden wären?

Miguel de Icaza: Ich habe nicht viel darüber nachgedacht, nein. Aber ich habe alle, die ich bei Microsoft interviewt habe, gebeten, internet-Explorer zu Open Source, bevor Netscape Communicator open-sourced war.

Dare Obasanjoist senior am Georgia Institute of Technology und arbeitet an seinem Bachelor of Science in Informatik. Er verbringt seine Freizeit damit, in Online-Foren wie Slashdot, Kuro5hin und Advogato zu posten und verschiedene Artikel über Programmierung und Software zu schreiben. Er hat für verschiedene Unternehmen wie Radiant Systems, i2 Technologies und Microsoft interniert und debattiert derzeit über die Vorteile eines Abschlusses, wird aber höchstwahrscheinlich in Redmond enden, wenn seine Zeit bei GA Tech vorbei ist.