Interview: Ajax-Entwicklung in PHP soll einfacher werden

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.