Interview: Ajax-Entwicklung in PHP soll einfacher werden
Golem.de: Wie sieht es mit den Veränderungen bei PHP 6 aus? Sie haben das Thema Unicode angesprochen. Was können wir noch erwarten?
Suraski: Ganz ehrlich und ich gebe Ihnen eine ganz ehrliche Antwort: Ich weiß es zum jetzigen Punkt nicht. Der Grund dafür ist nicht, dass wir uns nicht mit diesen Dingen beschäftigen. Aber ich bin mir nicht sicher, ob die Dinge, über die wir heute sprechen, wirklich erst mit PHP 6 eingeführt werden. Ein einfaches Beispiel sind "Namespaces", nach denen in den vergangenen drei oder vier Jahren der Ruf laut wurde. Wir hatten zunächst daran gedacht, "Name Spaces" in PHP 5.0 zu überstützen, uns fehlte aber die Zeit dafür. Daher entschieden wir uns dagegen, mit den Folgen der Entscheidung lebten wir. Heute verfolgen wir einen anderen Ansatz und werden "Namespaces" in Zukunft unterstützen. Wir haben einen sehr schönen Ansatz für PHP-Namespaces entwickelt und uns entschieden, es in PHP 6 zu integrieren. Zum gegenwärtigen Zeitpunkt erwägen wir aber, dies schon mit PHP 5.3 einzuführen. Mit der Entwicklung haben wir gerade begonnen und der Code wird voraussichtlich im 1. Quartal 2008 verfügbar sein, aber das kann sich noch ändern. Sehr wahrscheinlich werden also Name Spaces unterstützt. Wir wollen bei solchen kritischen Funktionen nicht auf PHP 6 warten. Sehr wahrscheinlich wird es noch weitere wichtige Funktionen geben, die die Anwender schon vor PHP 6 nutzen können. Wir wollen nicht auf PHP 6 warten, da wir bislang nicht genau wissen, wann diese Version verfügbar sein wird. Wir wollen unter anderem bei der Migration alles richtig machen und auf jeden Fall prüfen, ob wir es als Teil von PHP 5, im Rahmen einer neuen PHP 5-Version, anbieten können. Ich kann zum gegenwärtigen Zeitpunkt nur Unicode und einige Änderungen beim PHP-Setup nennen, die wir gerne umsetzen würden. So beispielsweise "Registered Globals" usw. bei PHP 6. Alles andere wird sehr wahrscheinlich mit PHP 5.3 oder 5.4 kommen. Hier warten wir nicht bis PHP 6.
Golem.de: Vor einigen Monaten kam Zend Framework 1.0 auf den Markt. Aus welchem Grund wurde eine andere Basis-Bibliothek für PHP entwickelt und nicht mit dem PEAR-Projekt oder eZ gearbeitet?
Suraski: Es gibt eine Reihe von Gründen, weshalb wir uns für Zend Framework entschieden haben. Andi und ich haben verschiedene andere Frameworks geprüft, bevor wir vor fast zwei Jahren, 2005, unser Framework-Projekt ankündigten. Es gibt verschiedene Gründe dafür, ein neues, eigenes Framework anzubieten. Der wichtigste Grund: 1. Wir wollten hier wirklich die Vorteile von PHP 5 nutzen. Wir wollten kein Framework, das einfach nur mit PHP 5 kompatibel ist, sondern ein Framework, das sich wirklich die Objektunterstützung von PHP 5 und den neuen ausgezeichneten Webservice-Support von PHP 5 zunutze macht. Das war mit den alten, in 2005 vorhandenen Frameworks nicht möglich, die eher auf PHP 4 abgestimmt und bestenfalls mit PHP 5 kompatibel waren. Wenn man PHP 5 nutzt, bieten sich auch andere Möglichkeiten, um das Framework zu erweitern und beim Zend Framework sind die Erweiterungsmöglichkeiten ein Schlüsselelement. Wenn die Basisimplementierung nicht zu 100 Prozent in PHP 5 realisiert ist und das Objektmodell von PHP 5 nicht konsequent genutzt wird, dann hat man wirklich Probleme bei der eleganten und effizienten Erweiterung im Vergleich zu einer echten PHP 5 Anwendung.
Ein weiterer wichtiger Aspekt sind die Rechte am Code: Als wir mit dem Zend Framework begannen, entwickelte sich die Partnerschaft mit IBM und ein wichtiges Anliegen von IBM und anderen Unternehmen, die PHP einsetzten, war die Verfügbarkeit eines Frameworks, bei dem die Rechtesituation klar ist: Es sollte deutlich werden, welche Teile von wem kommen. Die Anbieter sollten erklären, dass es sich tatsächlich um Eigenentwicklungen handelt und der Code nicht von anderen stammt. SCO spielt derzeit zwar keine Rolle mehr, aber damals und auch heute noch wollen Unternehmen sicher sein, dass ihnen keine Klage ins Haus flattert - von Unternehmen, die sagen: „Dieses Plug-in stammt von mir, ist urheberrechtlich geschützt und hört auf, es als Eures auszugeben." Das war der Punkt, an dem bei uns die Entscheidung fiel, ganz von vorn anzufangen. Wir haben nicht auf Bestehendem aufgebaut. Jeder, der etwas zu Framework beisteuert, muss ein „Contributor Licence Agreement" (CLA) unterzeichnen. Das gilt auch für Mitarbeiter von Zend, die Entwicklungen für Framework realisieren. Auch sie müssen ein CLA unterschreiben. Sie müssen „schwören", dass sie wirklich etwas ganz Neues beigesteuert haben, eine Eigenentwicklung, die nicht von jemand anderem stammt. Das gibt ein gewisses Maß an Sicherheit.
Das sind die beiden wichtigsten Punkte, neben einer Reihe vernachlässigbarer Gründe. Wir wollten vor allem den Qualitätsaspekt unterstreichen. Qualität kann etwas sehr Subjektives sein. Aber es gibt auch objektive Aspekte wie zum Beispiel „Coverage". Wir wollten ganz von vorn anfangen. Jede neue Komponente sollte ins Framework einfließen. Wir wollten umfassend testen, umfassende Sicherheit haben. Wir wollten, und das hat viel mit Psychologie zu tun, dass die Anwender wissen, dass das Produkt wirklich gut getestet ist. Das ist bei einem bestehenden Framework, das bislang noch gar nicht getestet wurde, schwieriger. Wenn man während der Entwicklungsphase viel testet, entwickelt man ganz anders. Das ist bei Framework passiert.
Golem.de: Wie viel Arbeit steckt Zend in das Framework?
Suraski: Sehr viel. Wir haben auf zwei Arten investiert: Zum einen stellen wir Leute für das Projekt ab, neben Andi Gutmans, mein Kollege und Mitbegründer von Zend, gibt es eine Entwicklergruppe, die ihm untersteht. Fünf oder sechs Entwickler arbeiten Vollzeit und ständig am Zend Framework. Sowohl Andi als auch die anderen, wichtigen Entwickler und Manager im Unternehmen, haben sich hier sehr stark engagiert. Das gilt auch für die Marketing-Mannschaft, die aus F&E-Projekten Produkte macht. Dann ist da Studio mit dem entsprechenden Support. Wir planen für die Zukunft die Integration in Platform und die Integration in Core.
Golem.de: Wo steht das Zend Framwork heute?
Suraski: Ich denke, wir haben bereits eine gute Position erreicht. Seit der Einführung der Framework-Site Ende 2005 bzw. Anfang 2006 hatten wir mehr als zwei Millionen Downloads. Darunter fallen auch etwa eine Million Downloads der Version 1.0, wenn ich mich richtig erinnere. Das ist bei fünf oder sechs Anwendungen sehr viel. Wir haben eine klare Vorstellung davon, in welche Richtung sich Framework entwickeln soll. Bei den Releases wollen wir eher einem bestimmten Zeitplan folgen, statt Feature-basierte Veröffentlichungen anzubieten. Neue Versionen des Zend Framework sollen zu bestimmten, vorhersehbaren Zeitpunkten erscheinen. Derzeit arbeiten wir noch an der Version 1.01. Diese wird eher unbedeutende Korrekturen erhalten und der Version 1.0 stark ähneln. Die Reaktionen sind bislang sehr, sehr positiv. Wir bekommen auch Rückmeldungen aus der Community, der Open Source-Community und von vielen Unternehmen, die das Produkt einsetzen. Ein Grund dafür ist übrigens, dass einige dieser Unternehmen an der Entwicklung und den Tests von Framework vor der Einführung mitgearbeitet haben. Dadurch konnten wir sicherstellen, dass sie mit dem Endprodukt zufrieden sind.
Bei den nächsten Schritten verfolgen wir zwei Ansätze. Zum einen ändern wir, wie bereits erwähnt, die Entwicklung von Framework dahingehend, dass wir neue Versionen zu bestimmten Terminen veröffentlichen. Zum anderen werden wir das Produkt mehr und mehr in die anderen Produkte von Zend integrieren: Natürlich in Studio, aber auch in Platform und Core. Jedes zukünftige Produkt von Zend wird das Framework unterstützen.
Golem.de: Es gab vor einigen Monaten eine öffentliche Auseinandersetzung mit Stefan Esser über die Sicherheit von PHP. Mein Eindruck ist, dass das PHP-Team die Art und Weise, wie Sicherheitspatches kommuniziert werden, leicht aber nicht grundsätzlich geändert hat. Was hat sich verändert, seit Stefan die Sicherheits-Debatte öffentlich angestoßen hat?
Suraski: Ich persönlich bin mit vielen öffentlichen Aussagen von Stefan nicht einverstanden. Alles in allem war es, auch wenn ich damit nicht der landläufigen Meinung folge, gut für PHP. Auch wenn ich mit Stefan nicht konform gehe, dass es eine vorsätzlich initiierte Verschwörung gab. Das hat er so nicht gesagt, es ist meine Interpretation der Geschehnisse. Es gab aber keinen absichtlichen falschen Umgang mit Sicherheitsproblemen von PHP im Netz. Antworten wurden nicht absichtlich hinausgezögert. Wir haben viele Dinge, die in einem bestimmten Licht wahrgenommen wurden, nicht getan. Allerdings hat man wohl Folgendes vergessen: Zum einen ist die Sicherheit von PHP größer geworden. Das ist positiv, da eine ganze Reihe von Sicherheitsproblemen offensichtlich wurden. Zum anderen hat es noch eine positive Konsequenz gehabt und das ist ganz wichtig: Es wurden Sicherheitsprobleme erkannt und behoben - positiv für PHP. Was unsere Vorgehensweise bei Sicherheitspatches angeht, so bin ich nicht sicher, ob sich da viel geändert hat. Ich denke, wir agieren bei dem Aspekt Sicherheit vielleicht etwas vorausschauender und reagieren schneller als früher. Es ist aber nicht so, dass wir heute dafür einen Tag brauchen und früher uns einen Monat Zeit ließen. Wir reagieren auf Sicherheitsprobleme viel schneller als in der Vergangenheit. Das hat aber nichts Revolutionäres an sich. Eines hat sich geändert, seit Stefan hier auf Sicherheitslücken bei PHP hingewiesen hat. Zur gleichen Zeit brachte Zend damals Zend Core 2 heraus. An der Version wurde etwa ein Jahr gearbeitet und ein wichtiger Aspekt bei Core hat mit Sicherheit zu tun. Das heißt nicht, dass Core sicherer als PHP ist. Core ist im Wesentlichen mit PHP identisch, aber wir bieten Hotfixes für Abonnenten von Zend Core. Man braucht sich also keine Gedanken mehr darüber zu machen, ob man die neueste PHP-Version installiert hat. Man muss nicht mehr prüfen, ob es ein Sicherheitsupdate für eine bestimmte neue PHP-Version gibt usw. Wenn Sie Core nutzen, informieren wir Sie als Abonnent oder Sie führen regelmäßig ein Update durch bzw. aktualisieren das System. Sie können Zend vertrauen, da wir alle Sicherheitspatches für PHP auf einen Server stellen. Sie profitieren von Core und brauchen nicht die neueste PHP-Version. Sie können jede beliebige, unterstützte Version von Zend Core einsetzen. Das ist ein großer Vorteil. So lange Sie Abonnent sind, erhalten Sie die Sicherheitspatches im Rahmen eines Backporting.
Golem.de: Sind diese Hotfixes auch kostenlos bzw. im Quellcode verfügbar?
Suraski: Die Hotfixes basieren alle auf der Open Source-Version von PHP. In der Regel veröffentlichen wir keine Backports. Man nimmt ein wenig von der neuesten PHP-Version für die alte PHP-Version und baut dann auf. Für mich ist Zend Core ein Abonnementforum, ein Service, den wir Ihnen zur Verfügung stellen und der Ihnen Benutzerfreundlichkeit vermitteln und Vertrauen schenken soll. Dazu haben wir Leute mit technischem Know-how, die jeden Patch bis ins Kleinste prüfen, sicherstellen, dass er gut ist, und dafür sorgen, dass die Kunden alle Patches bekommen. Die Kunden sollen aber nicht für geistiges Eigentum zahlen, sondern nur für den Dienst. Ich kann Ihnen daher sagen, dass alle bislang verfügbaren Patches für Zend Core 2 von PHP.net stammen, allerdings haben sie nichts, was Core-spezifisch ist. Außerdem ist das keine einseitige Beziehung, da viele Patches, die wir in Core implementiert haben, Eigenentwicklungen sind und von uns auf PHP.net zur Verfügung gestellt wurden. Wir reagieren zuweilen auf E-Mails, die uns über securitypeople.net erreichen - dort gibt es eine Zend-Liste - und entwickeln Patches, stellen diese zunächst auf PHP.net ein und arbeiten sie dann in die Hotfixes für Core ein. Das ist eine symbiotische Beziehung, die für uns gut funktioniert.
Golem.de: Ich möchte gern auf den Punkt Kommunikation von Sicherheitspatches, Sicherheitsfehlern zurückkommen. Ich habe noch immer den Eindruck, dass Informationen hierzu von Seiten der PHP-Entwickler recht spärlich fließen. Wenn man sich die Relase Notes anschaut, so findet man Links zu Fehlerberichten, aber nicht zu Sicherheitspatches. Es gibt immer nur ein paar sehr knappe Beschreibungen. Warum?
Suraski: Wenn es ernsthafte Probleme gibt, Remote-Exploits oder Sicherheitslücken, die ein ganz offensichtliches Problem eines jeden Setups sind, dann raten wir den Anwendern direkt zu einem Update. Die meisten Sicherheitspatches der letzten sechs bis zehn Monate - wozu auch die meisten Patches gehörten, die wir als Reaktion auf die vielen, von Stefan Esser genannten PHP-Fehler bereitgestellt haben - waren eher relativ unspektakulär. Wie viele andere Software-Features auch, kommen diese mit der nächsten Version. Das Update ist nicht kritisch. Das gilt beispielsweise für PHP 5.2.4.
Vielleicht will man auch nicht bei PHP 5.2.3 bleiben. Es gibt eine Reihe ganz spezieller, aber lokaler Sicherheitsprobleme. Wenn Sie die sicherste Version wollen, dann sollten Sie ein Update durchführen. In der Regel ist es nicht schlimm, wenn Sie dies nicht tun.
Was Informationen zu Sicherheitsproblemen angeht, ist das immer ein Kompromiss. Bei der Menge an Informationen ist es für Nutzer nicht immer einfach, zu entscheiden, ob jetzt ein Update notwendig ist oder nicht. Es ist nicht einfach, wenn man das Sicherheitsproblem genau kennt und nicht sicher ist, ob man nun betroffen ist oder nicht. Es ist ein Kompromiss zwischen den Informationen, die die Nutzer benötigen und ganz spezifischen Informationen über den Schutz des Systems, die dann vielleicht Hackern gerade recht kommen. Bei sehr kritischen Problemen stellen wir eher genaue Informationen und Update-Anweisungen zur Verfügung. Bei kleineren Problemen sagen wir eher, dass es ein Problem gab. Sie lesen dann in den Release Notes, dass es in einem bestimmten Systembereich ein Problem gab, das nicht näher ausgeführt wird. Das ist Absicht. Wir möchten den Anwendern keine spezifischen Informationen zu dem System zur Verfügung stellen. Ich weiß, dass das manche für ein Versäumnis halten. Manche sind der Meinung, dass immer alles offengelegt werden sollte. Andere vertreten die Ansicht, man solle nicht zu viel preisgeben. Darum geht es im Moment. Wir befinden uns irgendwo dazwischen, tendieren eher dazu, alles offenzulegen und nichts zu verschweigen, müssen aber aufpassen, dass wir nicht alles preisgeben.
Golem.de: Was können wir in der näheren Zukunft von Zend erwarten?
Suraski: Vor einem halben Jahr habe ich über eine Sache gesprochen, die relativ langwierig ist, da wir alles richtig machen wollen. In der ersten Hälfte des kommenden Jahres möchten wir Werkzeuge anbieten, um Ajax-basierte Anwendungen mit PHP viel schneller zu entwickeln, Zend Framework um Ajax-Komponenten erweitern. Wir möchten vieles automatisieren, ein einfach zu handhabendes Komponentenmodell entwickeln und ein WYSWYG-Setup in Zend Studio schaffen.
Golem.de: Fangen Sie also ganz von vorn an, wie beim Framework?
Suraski: Wir werden die Ajax-Tools wahrscheinlich nicht ganz neu entwickeln und wohl einige der vorhandenen Frameworks, sehr wahrscheinlich Dojo, einsetzen, da dieses von vielen unterschiedlichen Unternehmen unterstützt wird. Einzigartig dabei ist wohl, dass wir mit unserer Sichtweise sehr auf PHP zentriert sind. Wir werden dafür sorgen, dass die Entwicklung überwiegend mit PHP-Objekten erfolgt, um Dojo herum, statt mit JavaScript. Die Entwicklung mit PHP ist meiner Ansicht nach, was die Sprache und die verfügbaren Tools angeht, viel einfacher als die Entwicklung mit JavaScript. Wir fangen ganz von vorn an, aber nicht auf der JavaScript-Ebene, sondern der darüberliegenden.
Golem.de: Hört sich an, wie das Google Web Toolkit für PHP statt Java?
Suraski: Unser Ansatz ist anders, da wir nicht auf die gleiche Weise kompilieren. Google macht hier etwas sehr Interessantes. Sie entwickeln im Grunde in Java und verwenden einen Compiler, der den Code in JavaScript umwandelt, der Java-Code verschwindet. Wir gehen zwar ähnlich vor, aber das Konzept ist ein wenig anders. Wir entwickeln in PHP und stellen das auch zur Verfügung. Es gibt keine Kompilierungsphase und wir wollen PHP in JavaScript umwandeln.