amiga-news.de - AROS: Deutsche Übersetzung des Interviews mit Robert Norris

16.Nov.2007

AROS: Deutsche Übersetzung des Interviews mit Robert Norris
Robert Norris arbeitet zur Zeit an einer Portierung der Browser-Engine WebKit auf AROS. Ein gestern von Paul J. Beele veröffentlichtes Interview mit Norris hat amiga-news.de-Leser Björn Breuer freundlicherweise für uns ins Deutsche übersetzt. Wir bedanken uns herzlich bei Björn!

Wann planen sie den Namen zu veröffentlichen?

Jetzt und hier! Der Browser wird den Namen "Traveller" (britische Schreibweise, mit zwei "l") haben. Ich hatte ihn schon vorher als möglichen Namen in Erwägung gezogen, noch bevor ich mir Ideen eingeholt habe. Als denn ein paar Leute ihn auch vorschlugen, wusste ich dass er gut war.

Die Gründe dafür sind folgende:

Er passt gut zu "Wanderer" [der AROS-Workbench, Anm. d. Red.]
Er verfolgt die Tradition, Browsern einen Namen zu geben etwas Unbekanntes zu finden, Ähnlich wie "Navigator", "Explorer", "Konquerer", "Safari", etc.
Er bezieht sich auf einen Insider-Witz unter den Mitgliedern meines Teams auf meiner Arbeit, also ist es auch etwas Persönliches von mir.

Sind sie über das Feedback überrascht gewesen, das Sie bekommen haben als sie den neuen Webbrowser benannt haben?

Ich gestehe, dass ich durch das Fragen nach Ideen für einen Namen ein bisschen Hype erzeugen wollte, aber das Feedback war absolut unerwartet. Viele Leute haben mir ihre Meinung dazu angeboten und ich habe gemerkt, dass die großen Amigaseiten das auch schon verlinkt hatten. Was seltsam war - Ich hatte mich niemals wirklich als Amiga-User betrachtet. Vielleicht bin ich einer, ein kleines bisschen :)

Haben Sie schon einen Masterplan für die Entwicklung des neuen Browsers oder konzentrieren Sie sich hauptsächlich auf die Erfüllung der Bounty-Anforderungen?

Ich habe die Arbeit in zwei Stufen eingeteilt. Die Erste ist der Port von WebKit. Dies erfordert die Portierung der zwei WebKit Komponenten JavaScriptCore und WebCore und die Programmierung einer minimalen "Launcher"-Applikation, die lediglich ein einzelnes Browserfenster öffnet, damit die Engine getestet werden kann. Diese Stufe benötigt ebenfalls die Portierung verschiedener Libraries, die WebKit benötigt und die die Lücken in AROS schließen.

Die zweite Stufe ist die Integration der Engine in AROS selbst. Dies umfasst die Erstellung eines Zune-Widgets, welches WebKit umschließt und jeder Zune-Anwendung erlauben wird die Engine zu nutzen, falls ausgewählt. Letzendlich kann die Entwicklung des "richtigen" Traveller, also eines Zune-basierender Browsers, beginnen.

Planen sie Funktionen wie Tabs und Lesezeichen zu integrieren?

Ursprünglich nicht. Mein Ziel zur Erfüllung der Bounty ist nur ein grundlegendes Browser User-Interface: Navigationsleiste mit "Zurück", "Vorwärts", "Stopp" und "Home"-Buttons. Funktionen wie Tabs, Lesezeichen und Andere können später hinzugefügt werden. Ich weiß noch nicht, ob ich derjenige sein werde der das macht oder jemand Anderes. Meine Hoffnung ist, dass sich an diesem Punkt weitere Leute finden die an Arbeiten an Traveller interessiert sind. Ich möchte wirklich nicht für immer einen Web-Browser machen! Da gibt es zu viele andere Sachen in AROS die Arbeit benötigen und ich tendiere dazu mich zu langweilen wenn ich zu lange an einer Sache sitze. :)

Wie haben Sie entschieden, dass WebKit der richtige Weg sei um eine Browser-Engine auf AROS zu portieren?

Ein großer Teil meiner Programmiererfahrung besteht aus der Webprogrammierung - also weiß ich, dass das Web eine unglaublich komplizierte Sache ist und dass es eine beachtliche Menge an Code braucht um einen Browser zu schreiben, der nur eine kleine Menge davon zuverlässig handhaben kann.

Das Web ist auch bekannt für Probleme der Browserkompatiblität. Wir kennen alle aus eigener Erfahrung Webseiten , die mit dem Lieblingsbrowser nicht funktionieren.

Diese beiden Faktoren bedeuten, dass - wenn ein Browser für eine Nischenplattform wie AROS geschrieben werden soll, auf der man nicht die Resourcen hat um soviel Code zu entwickeln und zu warten - man auf einen etablierten Browser setzt, dessen Marktanteil groß genug ist - damit man sich um die Komplexität des Webs selbst keine Gedanken zu machen braucht.

Als ich das entschieden habe, war es so dass ich mich umgeschaut habe welcher freie Browsercode existiert und welchen ich nutzen konnte. Für lange Zeit gab es da nur eine Alternative, und das war natürlich Gecko, die Firefox-Engine. Es ist schon etwas länger her seit ich mir den Code angesehen habe, aber ich erinnere mich dass es fast unmöglich war ihn zu durchblicken oder ihn zu modifizieren. Ich habe mich in letzter Zeit nicht mehr viel damit befasst aber ich habe gehört, dass sich daran nicht viel geändert hat. Ausserdem sind die Entwickler heute immer mehr auf Firefox fokussiert, so dass es schwierig ist Unterstützung für einen Port zu finden.

WebKit ist ein neueres Projekt (obwohl es seinen Ursprung in KJS und KHTML-Komponenten hat die KDE's Konquerer antreiben), also könnte man argumentieren, dass der Support dafür nicht so umfangreich im Web vorhanden ist, aber Apple hat damit fast alles richtig gemacht. Sie haben den Quellcode offen gelassen, jeden aktiv ermutigt seinen Beitrag dazu zu leisten und hart daran gearbeitet ihn kompakt, schnell und portabel zu belassen. Das hat sich ausgezahlt; WebKit ist die Grundlage des Safari-Browsers unter OS X (und seit kurzem Windows) und hat auch einen großen Anteil am mobilen Markt, vorangetrieben durch Nokia. Dann kam das IPhone und wir sehen dass Webseiten anstreben ihre Seiten darauf kompatibel zu machen. Google hat gerade ihr Telefonprojekt "Android" angekündigt, das auch WebKit nutzt.

Was wir hier also haben ist eine Browser-Engine, die auf alles portiert werden möchte und dabei immer besseren Support für das Web erfährt, und zwar von beiden Seiten. Meiner Meinung nach war es eine offensichtliche Wahl.

Da WebKit nun auf AROS portiert ist; Was ist noch zu tun um es zu einem brauchbaren Browser zu machen? Spezieller, was ist der Unterschied zwischen einer Browser-Engine und einem WebBrowser?

Erstens ist WebKit noch nicht portiert - Ich habe gerade erst begonnen. Die Javascript Engine funktioniert, aber die Web Engine wird viel mehr Aufwand benötigen.

Der beste Weg um zu sehen was eine Browser Engine macht ist sich seinen jetzigen Browser anzusehen. Da gibt es eine Menge an Objekten wie die Menüs, Vorwärts/Rückwärts/Home-Tasten, Adresszeile, Tabs, Lesezeichen, Statusanzeige, etc. Und dann gibt es den Hauptteil des Fensters, in dem die Webseiten erscheinen. WebKit (oder Gecko, etc.) ist verantwortlich für den Webseitenteil. Die ganzen Dinge drumherum, die eine Engine zu einem richtigen Browser machen, nennt man "Chrome". Die wichtigste Sache dabei ist, die Engine mit dem restlichen Desktop zu verbinden.

Dieses "Chrome" wird gebraucht um Webkit in einen Browser zu verwandeln. Das ist es, was Traveller wirklich ist.

Ist das viel einfacher als einen Browser von Grund auf neu zu schreiben?

Absolut. Obwohl es schwierig ist WebKit beizubringen AROS Libraries, dessen Anzeige und Eingänge zu nutzen, ist es ein Kinderspiel im Vergleich zum Horror die ganzen Websachen neu zu programmieren.

Ich habe bemerkt, dass Leute fragen ob sie Firefox unter AROS nutzen können, da WebKit nun vorhanden ist. Aber Firefox nutzt nicht die WebKit Engine sondern Gecko. Der Mac Browser "Safari" nutzt hingegen WebKit. Ist das korrekt? Was sind ihre Gedanken diesbezüglich?

Das ist korrekt. Firefox hat mit WebKit nichts zu tun und der Port von Webkit würde einem Firefox-Port nicht helfen. (außer vielleicht in den Fällen, wo ich die AROS C Library verbessern musste oder unsere Compiler aktualisiert habe, von denen ein Firefox-Port potentiell gebrauch machen könnte.)

Um ehrlich zu sein sehe ich nicht viel Wert darin Firefox nach AROS zu portieren. Die Gecko-Engine könnte es wert sein (obwohl ich bezweifle dass wir "groß" genug für beide sind), aber Firefox wäre schlecht - es sieht einfach nicht wie eine AROS Applikation aus.

Wie würde ihrer Meinung nach der neue AROS Browser im Vergleich zu den anderen Amiga- und MorphOS-Browsern abschneiden; Zum Beispiel im Vergleich zu Sputnik, dem KHTML-basierenden Browser der für MorphOS portiert wurde, bzw. IBrowse oder AWeb, die für den Amiga verfügbar sind?

Ich habe keinen dieser Browser genutzt. Ich habe nur davon gelesen und Screenshots gesehen, aber soweit ich das beurteilen kann wird der Traveller sehr vorteilhaft abschneiden.

IBrowse und AWeb scheinen in der Unterstützung moderner Webfeatures zu weit zurück zu liegen um sie als wirklich relevant anzusehen. Wie ich schon vorher sagte sehe ich nicht den Sinn eines Webbrowsers der mit großen, Javascript-lastigen Seiten nicht arbeiten kann. Ich rede hier von GMail :)

Sputnik basiert auf dem S60 WebKit, eine Abzweigung des WebKits das von Nokia für ihre mobilen Geräte gemacht wurde. Ich gehe davon aus dass Traveller diesem am ähnlichsten werden wird. Soweit ich das gesehen habe wird der S60 Zweig allerdings nicht up-to-date mit den neuen Entwicklungen für WebKit gehalten. Das könnte bedeuten, dass der Traveller neue Features schneller erhalten kann.

Welchen Herausforderungen begegnen Sie bei diesem Projekt?

Da gibt es zwei wesentliche Dinge die das Projekt schwierig gemacht haben und es weiterhin machen werden. Das erste sind Defizite und Bugs in AROS selbst. Zum Beispiel benötigte der Port von JavaScriptCore einen System Call "posix_memalign()", der Speicher auf eine andere Art und Weise als normal alloziert. AROS hatte diesen Call nicht, also musste ich erst herausfinden wie er funktioniert und dann sehen wie AROS den Speicher alloziert bevor ich ihn implementieren konnte. JavaScriptCore benötigte außerdem einige Funktionen, die unsere Math-Library nicht besaß. Ich musste die Math-Library durch die FreeBSD-Quelle updaten, was mehr als eine Woche gedauert hat weil sich soviel darin verändert hatte. Jetzt habe ich Probleme mit unseren Netzwerklibraries weil diese nicht vollständig in den Kern integriert sind, was das Arbeiten mit ihnen ein bisschen erschwert.

Diese Sachen in Ordnung zu bringen ist üblicherweise sehr zeitraubend, aber es ist den Aufwand wert - weil AROS als Ganzes davon profitiert.

Die andere Herausforderung ist die WebCore-Portierung an sich. Es wird viel Arbeit sein, ihn in AROS zu verankern - aufgrund der Fülle an Aufgaben. Der Webcore muss Dinge auf den Screen zeichnen, Eingänge akzeptieren, Fonts und Bilder rendern, etc. Einige Sachen kenne ich bereits auf Seiten von AROS, andere nicht. Also werde ich diese erst lernen müssen. Mir wurde auch gesagt dass es noch einiges an Zeug gibt, dass WebCore-seitig implementiert werden muss um wenigstens eine minimale Funktionalität zu gewährleisten - etwas um die 70 Dateien. Ich habe mir das noch nicht genau angesehen aber es wird nicht einfach werden, auch wenn AROS alles bereitstellen würde was ich brauche und meine C++ Kenntnisse perfekt anstatt praktisch nicht existent wären

Neue Sachen zu lernen ist der einzige Grund warum ich so viel Zeit am Computer verbringe, also ist keins davon ein Problem. Es braucht nur Zeit.

Ich habe ihren Blog gelesen in dem es um die JavaScriptCore Engine in WebKit geht. Mussten sie etwas Spezielles tun um JavaScript zu portieren? Konnten sie den Code mit GCC kompilieren oder wie haben sie das gemacht?

JavaScriptCore ist ein JavaScript Interpreter - Er führt JavaScript-Code aus. Man braucht jedoch kein JavaScript um ihn zu kompilieren; Er ist in reinem C++ geschrieben.

Der Portierungsprozess ist interessant gewesen. Zuerst brauchte ich einen Compiler. WebKit muss mit GCC Version 4 kompiliert werden und natürlich ist es in C++ geschrieben. Wir hatten Patches für den GCC damit er Programme für AROS kompilieren konnte, aber die letzte Version die C++ Unterstützung hatte war Version 3. Wir hatten einen Version4-Patch, aber der war nur für C und nicht für C++. Also war das Erste was ich tat eine neue Kopie des aktuellen GCC zu nehmen (4.2.2) und C++ ans Laufen zu bringen.

Als ich dann einen Compiler hatte, modifizierte ich das WebKit Build-System so dass ich es nutzen konnte und startete es. Jedes Mal wenn der Compiler-Durchlauf fehlschlug, reparierte ich den Fehler und versuchte es erneut. Ein paar Sachen benötigten kleinere Mengen an Code um unter AROS zu laufen. Andere Sachen benötigten Änderungen in AROS selbst, wie das Beispiel mit der Math-Library, welches oben erwähnt wurde.

Letztendlich lies sich das Projekt compilieren und produzierte das JavaScriptCore Testprogramm "testkjs". Ich kopierte dies auf meine AROS Installation, startete es und begann damit die Tests auszuführen.

Das Testprogramm berichtete einige ungewöhnliche Probleme, also muss ich zurück zum Code und kleinere Sachen ändern. Die Leute im #webkit IRC-Kanal haben mir eine Menge geholfen und zeigten mir wie verschiedene Teile des Codes funktionieren.

Übrigens ist das so ziemlich der ganze Prozess zum Portieren einer Applikation oder einer Library. Dem System für das Projekt beibringen wie man AROS Compiler nutzt, den Code hacken bis man einen Build erhält, dann testen und die Bugs fixen.

Dies ist ein wirklich aufregendes Projekt! Ich bin sehr davon begeistert! Ich bin froh dass sie sich entschieden haben daran zu arbeiten und wünsche ihnen alles Gute!

Danke! Ich bin auch sehr erfreut! Und danke für die interessanten Fragen, sie haben mir geholfen sicher zu sein dass ich genau weiß was ich hier versuche zu tun :) (cg)

[Meldung: 16. Nov. 2007, 14:47] [Kommentare: 10 - 19. Nov. 2007, 12:40]
[Per E-Mail versenden] [Druck-Version] [ASCII-Version]

< Nächste Meldung

Vorige Meldung >