Dieser Artikel stellt Stream Wrappern in PHP vor und zeigt anhand von existierenden Anwendungs-Beispielen was alles so möglich ist.

PHP Streams sind doch auch nur Dateien, oder?

Bei Streams handelt es sich um ein Konzept um Dateien und Zugriff auf eben diese abzubilden. Hört sich theoretisch an, bedeutet aber verkürzt nichts anderes, als das man auf Dateien oder meist ein größere Menge von Daten zugreift. Jeder PHP Entwickler, der einmal auf eine Datei zugegriffen hat, setzt Streams bereits ein. So einfach ist das. Warum also einen Artikel darüber schreiben? Unter der Haube, hat PHP einiges zu bieten und das mit den Dateizugriff ist auch verkürzt. Aber von Anfang an.

Ein wesentliches Merkmal von Streams in PHP ist, dass sich fast alles in der Pfadangabe abspielt, also die Zeichenkette mit der ein Datei- oder Verzeichnisname angegeben wird. In der eigenen Anwendung braucht beim Dateizugriff sonst erstmal kaum etwas weiter beachtet werden.

So können mit den bei PHP von Haus aus eingebauten sog. Stream-Wrappern (dazu später mehr) die bekannten Internetprotokolle wie HTTP oder FTP (um nur zwei zu nennen) genutzt werden, ohne dass die eigene Anwendung irgendwelche Details der Protokolle beachten müsste.

Um dies an einem einfachen Beispiel zu verdeutlichen, habe ich die PHP Funktion file_get_contents() gewählt. Es soll eine CSV Datei geladen werden:


$data = file_get_contents('/var/www/data/cities.csv');


Hier kann – passende PHP Konfiguration vorausgesetzt – auch per HTTP eine Datei geladen werden, ohne den Programmablauf grundlegend zu verändern. Lediglich der Pfad-Parameter erhält eine neuen Wert:


$data = file_get_contents('http://localhost/data/cities.csv');


Das obere Beispiel dürfte bekannt sein. Hier werkelt der Standard-Wrapper, der genau genommen auf file:// hört. Dieses im PHP-Jargon genannte Scheme oder Protocol ist am Design von URLs orientiert, muss aber für den Dateizugriff wie man ihn erstmal kennen lernt, nicht explizit mit angegeben werden. Zuständig für alle “normalen” Dateizugriffe ist hier der Filesystem Wrapper. Er kümmert sich gemeinsam mit der Funktion um all dass, was oftmals lästig erscheint: Gucken ob die Datei da ist (auffinden), öffnen, lesen und schließen (unter dem Link wird u.a. auch erläutert wie genau Pfade bei Dateizugriffen aufgelöst werden).

Im zweiten Beispiel welches ebenfalls selbsterklärend sein dürfte, wurde lediglich die Pfadangabe mit einer HTTP URL ausgetauscht. Mehr war nicht nötig um das HTTP Internetprotokoll im Dateizugriff zu verwenden. Hierfür ist dann der HTTP Wrapper zuständig. Der wird auch aktiv, ohne das weiter etwas nötig wäre, den er ist bei PHP mit dabei.

Was hier im Beispiel so simpel daherkommt, wird durch Streams erst möglich gemacht. Statt auf eine Datei auf der Festplatte zuzugreifen, kann ich auch schnell mal was aus dem Netz laden. Streams vereinheitlichen den Zugriff auf Daten. Nun ist es mehr oder weniger egal geworden, wo die Datei liegt, auf der Festplatte oder auf einem Webserver. Meist nutzen wir dies tagtäglich beim Programmieren, ohne uns darüber weitere Gedanken machen zu müssen.

PHP stellt wie gesagt einige Wrapper bereit, die sich meist über die Pfadangbe nutzen lassen. Einige gibt es erst nach der Installation von PECL Extenstions. Einige Beispiel-Pfade um die Bandbreite zu verdeutlichen:

file:///path/to/file.ext
\\smbserver\share\path\to\winfile.ext
http://user:password@example.com
zip://path/to/textfile.odt#meta.xml
php://memory
compress.bzip2://
data://text/plain;base64,SSBsb3ZlIFBIUAo=
glob://ext/spl/examples/*.php
phar://my.phar/somefile.php
ssh2.shell://user:pass@example.com:22/xterm


Grenzen und Chancen der Abstraktion

Einschränkungen die solche Abstraktionsschichten mit sich bringen können schneide ich nur kurz an. So unterstützt nicht jeder Wrapper alle Stream Features, z.B. schreibenden Zugriff im Falle von HTTP. Ich kann die Daten nicht per HTTP wieder zurückschreiben. Und da sich nicht sämtliche Einstellungen jedes x-beliebigem Zielsystems (Protokoll) mit einer simplen Zeichenketten abbilden lassen (wie mache ich einen POST statt einem GET Request?), haben Streams auch einen Kontext (Stream Contexts) der die Möglichkeiten meist Stream-spezifisch erweitert. Mehr Informationen dazu in der Dokumentation.

Aber neben diesen Einschränkungen bieten Streams eine Menge Chancen, und die sind erstmal interessanter.

So unterstützen sie nicht nur Datei- sondern ebenfalls Verzeichnis-Operationen. Der besondere Clou: Neben den fest eingebauten Streamwrappern (die bereits sehr zahlreich sind) gibt es die Variante eigener, in PHP geschriebener Wrapper. Jeder kann also seinen eigenen Wrapper schreiben. Hierzu wird eine streamWrapper Klassen Vorlage verwendet die als Basis für den eigenen Wrapper dient und dann unter einer Protokoll (Scheme) registriert werden kann. Von da an durchlaufen sämtliche Zugriffe dieses Protokoll/Scheme die eigene Implementierung. Die Dateizugriffe “besuchen” die eigene Klasse. Beispielcode hat Nils Langer in seinem Artikel Streams – Ein kleines Beispiel.

Ebenfalls können PHP Erweiterungen in C geschrieben werden, die solche Wrapper bereitstellen. Darauf gehe ich hier allerdings nicht weiter ein, die PHP Dokumentation hält dazu Informationen bereit. Das gleiche gilt für Stream Filter, die ich ebenfalls leider hier nicht vertiefe – sie können aber eine Menge und ergänzen die Wrapper.

PHP Streaming Extravaganza

Aufgrund des im Grunde einfachen Konzeptes und des hohen Abstraktionsgrades als auch der Verwendung von Streams innerhalb vom PHP Core Code ergeben sich mannigfaltige Einsatzmöglichkeiten die vielen PHP Entwicklern gar nicht so bewusst sind. Dabei handelt es sich um eine absolute Unterbewertung dieses Features, denn hier macht es durchaus Sinn den Gedanken freien Lauf zu lassen: Von der Entkopplung des konkreten Dateisystem, der Erhöhung der Test- und Wartbarkeit des eigenen Codes bis hin zu verschiedenen Dateisystem-Backends oder gar eines transparenten Cachings, Skalierung und vielem mehr. Den eigenen Ideen sind nur wenig Grenzen gesetzt. Was soll ich schreiben?

Beispiel PIWI

Ein Beispiel aus der Praxis über das ich gestolpert bin und welches den Einsatz eines Stream-Wrappers verdeutlicht findet sich im (relativ jungem) PIWI Quellcode. Keine Ahnung ob das jetzt ein super Beispiel ist, es hat mir nur wieder mal vor Augen geführt wie weit man mit der Stream-Denke gehen kann und es hat mich auf weitere Ideen gebracht. PIWI ist ein XML-Transformations-Framework zur Web-Publikation von Inhalten. Dies macht Verwendung von PHP’s DOMDocument mit all seinen Fähigkeiten. Im Grunde alles bestehende PHP Bibliotheken, die bei Transformationen dieser Art gebräuchlich sind und Verwendung finden.

In einem der XSL-Stylesheets der Anwendung stolperte ich über eine Zeile, welche im XSL Stylesheet eine weitere Datei referenziert (vgl. mit einem PHP include nur für XSL), die bei Ausführung eingebunden werden soll:


<xsl:include href="xsltsss://customStyleSheet"/>


Meine IDE mäkelte diese Zeile an und dies machte mich neugierig, was es mit xsltsss auf sich hatte. Offensichtlich handelt es sich ja nicht um eine Datei und das Protokoll sagte mir auch nichts. Nach einem Blick in den Quellcode der Anwendung war die Auflösung relativ einfach. Das Puzzle an dem die IDE scheiterte: Auf diesem Protokoll wird im PHP Code ein eigener Stream-Wrapper registriert, der dynamisch zur Laufzeit ein Custom-Stylesheet erstellt (xsltsss = XSLT Style Sheet Stream).

Möglich wird der Einstaz des eigenen StreamWrappers erst dadurch, dass die PHP interne Klasse XSLTProcessor nicht “einfach nur” Dateizugriffe sondern sämtliche Streams verwenden. Dies machen auch andere PHP Klassen und Funktionen so. Streams gehen somit durch Mark und Bein einer jeden PHP Anwendung – ob man sie nun bewusst einsetzt oder nicht. Und das macht sie so interessant wie effektiv.

Falls dies Beispiel Interesse geweckt hat, das Haupt-Stylesheet befindet sich in der Datei HTMLTransformation-v1.0.xsl, der PHP Code des Wrappers in XSLTStylesheetStream.class.php und das Processing u.a. in der HTMLSerializer.class.php Datei.

Weitere Beispiele

Ein weiterer, etwas umfangreicherer Einsatz vom Streamwrapper findet sich im EGroupware Quellcode. Ich setzte den Code nicht ein, allerdings halte ich hier das Virtual File System (en) für erwähnenswert. So wie ich die Dokumentation gelesen habe wird hier ein komplettes Dateisystem implementiert, welches mehrere Backends sowie eine Benutzerverwaltung unterstützt. Ich kenne EGroupware nicht sehr genau, vermute aber, dass dieses System dafür eingesetzt wird, um mehrere Datei-Quellen (Repositories) innerhalb der Webanwendungs-Oberfläche den Benutzern zur Verfügung zu stellen. Diese sehen dann einen Verzeichnisbaum in dem Dateien eingeordnet werden – unabhängig davon, wo sich die Daten nun befinden. Ob in der Datenbank oder auf dem Server direkt oder sonst wo. Muss und soll den User ja auch nicht interessieren.

Das Netz hält noch einige weitere Inspirationen bereit (Surprise, Surprise). vfsStream stellt ein Virtuelles Dateisystem für Testing-Frameworks wie PHPUnit oder SimpleTest bereit; Anwendungen wie Drupal 7 planen die Unterstützung von Stream-Wrappern; und es finden sich Anwendungsbeispiele wie beim Refactoring eines Transport-Layers mittels Streamwrappern und der SPL um nur einige Beispiele kurz zu nennen.

Mehr als nur Dateien

Der Blick in die PHP Dokumentation kann also lohnend sein. Es gibt zwar keine PHP Konfigurations-Direktiven, die Standard Stream Wrapper bereits per PHP INI zu überladen, aber sie können per Funktionsaufruf de-registriert werden, um sie dann mit einem eigenen Wrapper zu ersetzen. Wer aufräumen mag oder muss, kommt mit stream_wrapper_restore() wieder auf Los zurück.

Soll der eigene Wrapper mehrere Subsysteme unterstützen, so ist ein pragmatischer Ansatz die Protokolle zu “stacken”, also im Pfad aufeinander zu staplen. Ein Beispiel dafür findet sich bei den Audio Streams:


ogg://http://www.example.com/path/to/soundstream.ogg


Theoretisch wäre mit den Grundmöglichkeiten, die PHP von Haus aus bereitstellt, es auch möglich ein komplett objekt-orientiertes Subsystem auf der Basis von Streams zu Entwickeln. Im PHP Manual gibt es einen Kommentar, der eine streamWrapper Interface Definition beinhaltet, das erscheint mir in jedem Falle praktisch. Und wer weiß, vielleicht gibt es ja eines Tages etwas in der SPL. Oder ein Informatikstudent schmeißt mal alles an Pattern drauf, was die Theorie so hergibt – könnte auch interessant werden, wenn es nicht schon bereits gemacht wurde. Ein System welches für das PHP Umfeld recht Hochgradig durchplant ist, das Flow3 Framework, setzt beispielsweise dezidiert auf Wrapper und beinhaltet ein eigenes Interface dafür.

Streams selber sind werden nicht unbedingt direkt als ein Design Pattern, werden aber nah dran eingeordnet (manche reden von Anti-Pattern was den Gesetzen der Dialektik folgend schon sehr nah wäre). Die Affinität bemerkt man auch, wenn man sich über Proxy oder Strategy im Zusammenhang mit Streams mal Gedanken macht. Im Grunde aber sind sie erstmal eine sehr erprobte Abstraktionsschicht. Einige Entwickler kennen das Prinzip von C, dass wie in den meisten Computer-Hochsprachen der Einsatz von Stream Abstraktion gebräuchlich ist. Das SPLFileObject – interessant für PHP Entwickler – unterstützt Streams bereits von Anfang an.

Beim Implementieren einer eigenen StreamWrapper Klasse ist es gut ein wenig Vorsicht walten zu lassen und darauf achten, dass das die Klasse genau das tut was sie auch tun soll und sämtliche Methoden und Eigenschaften des Klassen-Prototypen vorhanden sind. Ein Interface zu definieren ist sicherlich von Vorteil. Fehlerhafter Code kann zu unschönen Situationen führen, worauf auch die PHP Dokumentation hinweist. Von undefined behaviour ist hier die Rede – das kennt man als Programmierer ja vielleicht. Dies beachtend steht dem eigenen Wrapper nichts mehr im Wege.

Das Konzept von Streams sollte man als (PHP-) Entwickler kennen. Es eignet sich sowohl um bestehende Anwendungen weiter zu entwickeln, als auch Komponenten, welche Daten bereitstellen, in einfacher Weise anzubieten und zu integrieren. Auch können Neuentwicklungen oft von diesem Feature erheblich profitieren.

Meiner Meinung nach ist es ebenfalls sinnvoll das theoretische Konzept von Stream und Kontext ein wenig zu ergründen und damit zu spielen. Objekte in einem Kontext zu führen erweist sich oftmals als eine einfache Lösung, den eigenen Code modular zu halten was nur ein Aspekt ist.

Weiterführendes

• Streams – Ein kleines Beispiel – von Nils Langner am 22. März 2010.
• Streams – PHP Dokumentation für Streams.
• List of Supported Protocols/Wrappers – Liste der von Haus aus eingebauten Wrapper.
• The streamWrapper class – Prototyp der streamWrapper Klasse.
• stream_wrapper_register – Funktion zum Registrieren eigener Wrapper.
• Streams API for PHP Extension Authors – Informationen für C Implementierungen (PHP/Zend Engine 1)
• The Law of Leaky Abstractions – Aufsatz von Joel Spolsky zu Grenzen von Abstraktion
• Wrapper bei PHPDeveloper.org – Diverse Blog Posts zum Thema Stream-Wrapper

• Error Collection: Fehler einfach aufsammeln und später kontrolliert ausgeben.
• xdebug_get_headers(): Gibt alle bisher gesetzten HTTP-Antwort-Header zurück (egal ob per header() oder setcookie() gesetzt).
• “Scream” Support: @-Operatoren zu Testzwecken ausschalten.
• Und einiges mehr.

Die Xdebug Extension hilft beim Entwickeln in dem sie in einer einfachen Art und Weise zusätzliche Debug-Informationen bereitstellt. Daneben beinhaltet sie auch einen kompletten Debugger, der aus einer IDE wie Eclipse oder Netbeans genutzt werden kann.

Sie bietet also für beide Typen des Debuggen etwas: Sowohl für den “print_r() oder var_dump()-Typen” als auch den “interaktiven Typen”, der sich gerne mit Breakpoints durch den Code hangelt.

Release Notes

Eingefunden hatten sich Gäste aus Frankfurt und Umgebung mit verschiedenen beruflichen und fachlichen Hintergründen. Allen gemein war die Affinität zum Netz – egal ob auf mobilen oder festen Endgeräten, als Selbstständiger, Angestellter, oder Chef. Das Knüpfen von Kontakten und der Austausch von Neuigkeiten stand im Vordergrund.

Nach rund 8 Stunden Barbecue, PHP und interessanten Gesprächen waren sich alle einig: es hat sich gelohnt. Die Veranstaltung verdient eine Fortsetzung.
Die Zwischenzeit wolle man nutzen die UserGroup ein wenig wiederzubeleben. Auch der Sponsor zeigte sich mit der Resonanz zufrieden. Gern wieder im nächsten Jahr!

Besonderen Dank: Thorsten Rühl, dem Geschäftsführer von Spieletipps als Sponsor und der PHPUG für einen gelungenen Event.

Vielen Dank an Thomas Meyer, für diesen Text.

Mehr von und auf Geek and Poke.

Das PHP BBQ 2010 in Frankfurt am Main steht: Sonntag den 27. Juni ab 13:00 Uhr im Licht- und Luftbad am Niederräder Ufer. Die Teilnehmerzahl ist begrenzt, mehr Infos in der Mailingliste.

Pomodoro

Das Grundprinzip ist schnell erklärt: Kleine, regelmäßige Zeiteinheiten mit Pausenzyklen bei gleichzeitigem fixieren auf einzelne Arbeitsschritte. Die Pomodoro Technik eignet sich hervorragend zum Task oder Ticket orientierten Arbeiten oder iterativen Ansätzen (alles was nicht in 25 Minuten gecoded werden kann, muss man eh direkt neu refaktorieren).

Sie ist einfach und rockt. Das Beste daran: Es erfordert lediglich eine Eieruhr. Als Zyklus ist 25 Minuten plus 5 Minuten Pause angedacht, man kann also zwei Runden pro Stunde drehen wenn man die Pause nicht über dehnt. Ja und wenn 25 Minuten um sind, Hände von der Tastatur. Das ist jetzt verkürzt erklärt, es gibt natürlich ein Buch zu kaufen, das offizielle Set und so und Tonnen an Software:

The Pomodoro Technique™

Kanban

Kanban ist vielleicht einigen Leuten mit geschäftlichem Background ein Begriff. Das ganze für die Softwareentwicklung adaptiert, ergibt einen ausgeglichenen Weg (vielleicht wegen fernöstlicher Weisheit?) sich die Arbeit im Team zu organisieren.

Wer also statt mit den tendenziell eher stressigen extrem Programmieren komplette Prozesse umkrempeln will, dem bietet sich das von David J. Anderson adaptiere “Lean Production” Model an, das ganze mit mehr Flow angehen zu lassen. Ein deutschsprachiger Artikel findet sich in der iX Juni 2010.

royganor / zend-studio Tips-und-Tricks (englisch; Adobe Flash, Javascript oder ein Slideshare Account benötigt)

Die meisten Linux basierten PHP Setups kommen dieser Tage mit der Suhosin Extension von Stefan Esser. Und diese kann das. Eine kleine Einstellung aktivieren und schon führt der Aufruf von eval zum Abbruch des Skriptes:

suhosin.executor.disable_eval = On

Einfach in die php.ini damit und schon ist Ruhe im Karton.

Es ist übrigens noch gar nicht so lange her, dass noch eval Aufrufe im WordPress Quellcode waren. Der Patch demonstriert mit ein wenig objektorientierter Programmierung die einfache Implementierung eines “Statefull Automata” (Quellcode Dokumentation in englischer Sprache). Dieser macht die Verwendung von eval überflüssig um eine Substitution von Variabeln in einer Zeichenketter vorzunehmen (bei der Verarbeitung von Permalinks in WordPress).

Die einzige Frage die bleibt ist wie lange ein solcher Schutz vorhält. Kann ein Angreifer in Dateien schreiben (und sei es nur nach /tmp), so reicht es, den code über ein include() einzuladen. Oder aber allow_url_include = On ist gesetzt:

Via: Cheap Hack/Worm Protection for your WordPress Blog