Freigeben über

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

  • Artikel

 

Dare Obasanjo

Dezember 2001

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

Dare Obasanjo: Sie sind kürzlich in der Presse gewesen, weil Ximianankündigung, dass sie eine Open Source-Implementierung der Microsoft .NET-Entwicklungsplattformerstellt. Vor der jüngsten Furor haben Sie für die Arbeit, die Sie mit SHAPE und Bonobo getan haben, bemerkenswert. Können Sie einen kurzen Überblick über Ihre Beteiligung an freier Software von Ihren früheren Projekten bis zu Monogeben?

Miguel de Icaza: Ich arbeite in den letzten vier Jahren am PROJEKT ASPX in verschiedenen Bereichen: Organisation, Bibliotheken und Anwendungen. Vorher habe ich schon lange an dem SPARC-Port gearbeitet, dann am Software-Raid und an einigen auf linux/SGI-Aufwand. Davor hatte ich den Mitternacht Commander Dateimanager geschrieben.

Dare Obasanjo: In Ihrem Let es Make Unix Not Suck Serie erwähnen Sie, dass die UNIX-Entwicklung lange durch eine fehlende Codewiederverwendung behindert wurde. Sie erwähnen insbesondere Brad CoxKonzept von Software Integrated Circuits, wo Software hauptsächlich durch die Kombination wiederverwendbarer Komponenten erstellt wird, als Vision, wie die Codewiederverwendung erfolgen soll. Viele haben Ihren Argumenten entgegengegriffen, indem sie besagt, dass UNIX auf dem Konzept basiert, wiederverwendbare Komponenten zum Erstellen von Programmen zu verwenden, indem die Ausgabe kleinerer Programme mit Rohren verbunden wird. Was sind Ihre Meinungen zu diesem Gegenargument?

Miguel de Icaza: Nun, das Papier behandelt diese Frage ausführlich. Ein "Rohr" ist kaum ein komplettes Komponentensystem. Es handelt sich um einen Transportmechanismus, der mit einigen bekannten Protokollen (Zeilen, Zeichen, Puffern) 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 "Unix Components: Small is Beautiful."]

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

Miguel de Icaza: Ziel des PROJEKTS ENTERPRISE war es, fehlende Technologien auf Unix zu bringen und sie auf dem aktuellen Markt für Desktopanwendungen wettbewerbsfähig zu machen. Wir erkannten auch frühzeitig, dass die Sprachunabhängigkeit wichtig war, und deshalb wurden DIE RUNTIME-APIs mit einem Standard codiert, der es ermöglichte, die APIs für andere Sprachen einfach umschlossen zu werden. Unsere APIs sind für die meisten Programmiersprachen unter Unix verfügbar (Perl, Python, Scheme, C++, Objective-C, Ada).

Später haben wir beschlossen, bessere Methoden für die Kapselung unserer APIs zu verwenden, und wir begannen, CORBA zum Definieren von Schnittstellen zu Komponenten zu verwenden. Wir ergänzten sie durch Richtlinien und eine Reihe von STANDARD-RUNTIME-Schnittstellen für die einfache Erstellung wiederverwendbarer, sprachunabhängiger Komponenten, Steuerelemente und Verbunddokumente. 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 gut sind. Beispielsweise wäre eine XML-Analyse bonobo/CORBA-Komponente im Vergleich zu einer C-API ineffizient.

Ich schrieb auch irgendwann:

Mein Interesse an .NET stammt aus den Versuchen, die wir zuvor im PROJEKT ZUR ANWENDUNG von .NET gemacht haben, einige der Aktionen von .NET zu erreichen:

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

Und vor dingen, ich liebte immer verschiedene Dinge über Java. Ich liebte einfach nicht die Java-Kombination, die Sie geben oder nehmen sollten.

Wir haben versucht, APIs für viele Sprachen verfügbar zu machen, indem eine allgemeine Objektbasis (GtkObject) vorhanden ist, und dann nach einem API-Vertrag und einem Format, 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 automatisch zu generieren. Diese Lösung ist aus vielen Gründen suboptimiert.

Die sprachübergreifende Integration, die wir mit CORBA gemacht haben, wie COM, aber mit einer verhängten Marshall-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.

Auf diesem Problem haben wir eine Verbreitung von Bibliotheken. Die meisten folgen unseren Codierungskonventionen ziemlich genau. Jedes Mal in einer Weile würden sie entweder nicht oder wir würden eine Bibliothek übernehmen, die von einer anderen Person geschrieben wurde. Dies führt zu einer Mischung aus Bibliotheken, die zwar leistungsfähig sind, aber mehrere Programmiermodelle implementieren, manchmal unterschiedliche Zuordnungs- und Besitzrichtlinien und nach einer Weile mit 5 verschiedenen Arten von "ref/unref"-Verhaltensweisen (CORBA-lokale Verweise, CORBA-Objektverweise auf unbekannten Objekten, Verweisanzahl auf Objektwrapper) und dies wurde zu einem riesigen Chaos.

Wir haben natürlich versucht, all diese Probleme zu beheben, und es sieht besser aus (die PLATFORM 2.x löst viele dieser Probleme, aber dennoch).

.NET schien mir wie ein Upgrade für Win32-Entwickler: Sie hatten die gleichen Probleme, die wir beim Umgang mit APIs hatten, die über viele Jahre entworfen wurden, eine große Anzahl von Inkonsistenzen. Deshalb möchte ich einige dieser neuen "frische Luft" für die Erstellung meiner eigenen Anwendungen zur Verfügung haben.

Dare Obasanjo: Bonobo basiert leicht auf COM und OLE2, da die Bonobo-Schnittstellen alle auf der Bonobo::Unknown-Schnittstelle basieren, die zwei grundlegende Dienste bereitstellt: Objektlebensdauerverwaltung und Objektfunktionalitätsermittlung und nur drei Methoden:

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

das ähnelt der COM IUnknown-Schnittstelle von Microsoft mit den folgenden Methoden

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

Bedeutet die Tatsache, dass .NET implizieren scheint, dass das Ende von COM nahe bedeutet, dass Mono das Ende von Bonobo rechtschreibt? In ähnlicher Weise, da .NET plant, halbtransparente COM/.NET-Interoperabilitätzu haben, gibt es einen ähnlichen Plan für Mono und Bonobo?

Miguel de Icaza: Definitiv. Mono muss mit einer Reihe von Systemen zusammenarbeiten, darunter Bonobo auf DEM VORGANG.

Dare Obasanjo: Eine Reihe von Parteien hat behauptet, dass die Microsoft NET-Plattform ein schlechter Klon der Java-Plattform™ ist. Wenn dies der Fall ist, hat Ximian nicht beschlossen, 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 es ein Problem löst, das wir jeden Tag haben. Das Problem wurde von der Java-VM nicht behoben.

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

  • 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 zu diesem Zeitpunkt. Wir haben derzeit ein Engagement für die Entwicklung:

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

Alle oben mit Hilfe externer Mitwirkender. Sie müssen verstehen, dass dies ein großes Unternehmen ist und dass ohne die verschiedenen Personen, die ihre Zeit, Expertise und Code für das Projekt gespendet haben, wir hätten nicht einmal die Chance, ein komplettes Produkt in Kürze zu liefern.

Wir tun dies aus selbstsüchtigen Gründen: Wir wollen eine bessere Methode zur Entwicklung von Linux- und Unix-Anwendungen selbst und wir sehen die CLI als solche.

Das heißt, Ximian, das im Dienstleistungs- und Supportgeschäft tätig ist, würde nicht daran denken, seine Bemühungen, das Mono-Projekt andere Dinge wie das Portieren auf neue Plattformen oder die Verbesserung des JIT-Moduls oder die Konzentration auf einen bestimmten Bereich von Mono zu erweitern.

Aber anders als dies haben wir an diesem Punkt 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 scheinbar Reibung mit dem Mono-Projekt haben. Abschnitt 7.2 der Portable.NET FAQ scheint darauf hinzuweisen, dass sie mit dem Mono-Projekt in Konflikt stehen, wie das Verbot von Martin Coxall aus der dotGNU-Adressenliste. Was sind Ihre Gedanken zu diesem Thema?

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 andere Instanz davon, was normalerweise im Internet geschieht. Es ist definitiv traurig.

Der Fokus von Mono und .NET unterscheidet sich geringfügig: Wir schreiben so viel wie 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 die Beziehung von Ximian zu Microsoft. Einerseits gibt es Berichte, die zeigen, dass es möglicherweise Lizenzprobleme zwischen der Lizenz gibt, die .NET und die GPL regelt. Andererseits gibt es einen Hinweis darauf, dass einige innerhalb von Microsoft von Mono begeistert sind. Genau was ist also Ximians aktuelle Beziehung zu Microsoft und was wird getan, um sicherzustellen, dass Mono die Microsoft-Lizenzen auf .NET nicht verletzt, wenn sie restriktiv sind?

Miguel de Icaza: Nun, für eine schreiben wir alles von Grund auf neu.

Wir versuchen, bei Patenten auf der sicheren Seite zu bleiben. Das bedeutet, dass wir Dinge in einer Weise umsetzen, die in der Vergangenheit eingesetzt wurde und wir noch nicht enorm aufwändige oder effiziente Dinge in Mono machen. Wir sind noch sehr weit davon entfernt. Aber nur vorhandene Technologien und Techniken verwenden.

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 kein offener Standard ist?

Miguel de Icaza: Das Upgrade auf unserer Entwicklungsplattform hat unabhängig davon, ob es sich um einen Standard handelt oder nicht. Die Tatsache, dass Microsoft seine Spezifikationen an eine Standardsstelle übermittelt hat, hat geholfen, da Personen, die über diese Probleme wissen, das Problem betrachtet haben und Probleme für die Interoperabilität anheften können.

Dare Obasanjo: Was geschieht, wenn dan Kusnetzkys Vorhersage 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, um ihre APIs abwärtskompatibel zu halten (und dies ist einer der Gründe, warum ich glaube, dass sie so viel Erfolg als Plattformanbieter 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 haben und die richtige zu verwenden, indem sie zur Laufzeit die richtige "Assembly" auswählen. Assemblys sind eine neue Möglichkeit zum 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— Siehe beschreibung der Assemblys aus dem .NET Framework Glossar.]

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

Dare Obasanjo: Betrachten der Mono-Klassenstatusseite bemerkte ich, dass eine große Anzahl von .NET-Klassenbibliotheken nicht in Mono wie Windows Forms, ADO.NET, Webdienste, XML-Schemas, Spiegelung und eine Reihe anderer implementiert wird. Dies bedeutet, dass Anwendungen, die für .NET geschrieben wurden, nach der Veröffentlichung von Mono und .NET sehr wahrscheinlich nicht portierbar sind. Gibt es pläne, dies in Zukunft zu korrigieren oder eine tragbare .NET-Plattform zu schaffen, die kein Ziel des Mono-Projekts ist? Was sind die kurzfristigen und langfristigen Ziele des Mono-Projekts?

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

Wir befinden uns in den sehr frühen Phasen des Projekts, sodass Sie mehr Arbeit an den Grundlagenklassen sehen als bei den Endbenutzerklassen.

Ich hatte nicht einmal erwartet, dass so viele großartige und talentierte Programmierer so früh im Projekt mitwirken. Meine ursprüngliche Vorhersage ist, dass wir die ersten drei Monate hacking auf eigene Faust in der Öffentlichkeit ohne externe Beiträge verbringen würden, aber ich habe falsch bewiesen.

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 Mitwirkende des Projekts hat seine eigenen Ziele: einige Leute möchten lernen, einige Leute wie die Arbeit an C#, einige Leute möchten volle .NET-Kompatibilität unter Linux, einige Leute möchten Sprachunabhängigkeit, einige Leute möchten Code optimieren, einige Personen wie die Programmierung auf niedriger Ebene und einige Leute wollen mit Microsoft konkurrieren, einige Personen mögen die Funktionsweise von .NET-Diensten.

Die Richtung des Projekts wird also von denjenigen gesteuert, die dazu beitragen. Viele Personen sind sehr daran interessiert, eine kompatible .NET-Implementierung für Nicht-Windows-Plattformen zu haben, und sie tragen dazu bei, diese Lücken zu füllen.

Dare Obasanjo: Wie plant Ximian, die Kosten für die Entwicklung von Mono zu zahlen, insbesondere nach dem Scheitern einer Reihe von venture-finanzierten, kostenlosen softwarebasierten Unternehmen wie Indrema, Eazel und Great Bridge, und die Tatsache, dass ein sizabler Prozentsatz der verbleibenden freien Software-basierten Unternehmen auf den Seilen sind? Insbesondere wie plant Ximian, geld bei freier Software im Allgemeinen und Mono zu verdienen?

Miguel de Icaza: Ximian bietet Support und Dienstleistungen. Wir haben kürzlich einige unserer Dienstleistungen angekündigt, und in den nächsten sechs Monaten sind noch mehr Produkte und Dienstleistungen in der Pipeline.

Diese, die wir kürzlich angekündigt haben, sind:

  • Red Carpet Express: ein Abonnementservice für diejenigen, die zuverlässigen, hochgeschwindigkeits-Zugang zu den Red Carpet-Servern wünschen.
  • Red Carpet Corporate Connect: Wir haben unsere Red Carpet Updater-Technologie geändert, um Personen bei der einfachen Verwaltung von Netzwerken von Linux-Workstations zu helfen und benutzerdefinierte Softwarepakete bereitzustellen und zu verwalten.
  • Support und Dienstleistungen für den DESKTOP UND die EVOLUTION: Unsere neuesten Boxprodukte sind unsere Art, Support-Dienstleistungen für die verschiedenen Produkte zu verkaufen, die wir versenden.

Wir bieten auch professionelle Dienstleistungen und Support für Menschen, die kostenlose softwarebasierte Lösungen integrieren.

Der besondere Fall von Mono ist interessant. Wir arbeiten an Mono, um unsere Entwicklungskosten zu reduzieren. Ein sehr schönes Fundament wurde gelegt und der ECMA vorgelegt. Mit Hilfe anderer interessierter Parteien, die auch die Leistungsfähigkeit erkennen, entwickeln wir nun die Mono-Laufzeit- und Entwicklungstools, um uns dabei zu helfen, unsere Produktivität zu verbessern.

Das Team, das an Mono bei Ximian arbeitet, ist in der Tat dasselbe Team, das infrastrukturelle Hilfe für den Rest des Unternehmens in der Vergangenheit bereitgestellt hat.

Dare Obasanjo: Es ist wahrscheinlich in einigen Ecken wenig bekannt, dass Sie einmal mit Microsoft interviewt haben, um an der SPARC-Port von Internet Explorer zu arbeiten. Angesichts der Auswirkungen, die Sie seitdem auf die freie Software-Community hatten, haben Sie sich schon einmal gefragt, wie Ihr Leben wäre, wenn Sie ein Microsoft-Mitarbeiter geworden wären?

Miguel de Icaza: habe ich es nicht viel gedanken gemacht, nein. Aber ich habe alle fragen, die ich bei Microsoft befragt habe, um Internet Explorer zu öffnen, so bevor Netscape Communicator open-sourced wurde.

Dare Obasanjoist ein Senior am Georgia Institute of Technology, der an seinem Bachelor of Science in Informatik arbeitet. Er verbringt seine freie Zeit in Onlineforen wie Slashdot, Kuro5hin und Advogato sowie schreiben verschiedene Artikel über Programmierung und Software. Er hat für verschiedene Unternehmen wie Radiant Systems, i2 Technologies und Microsoft interniert und diskutiert derzeit die Verdienste eines Graduiertenabschlusses, wird aber höchstwahrscheinlich in Redmond enden, wenn seine Zeit bei GA Tech vorbei ist.