Technik

Ein wenig naiv war ich gestern in meinem logischen Denken irgendwie schon. Aber was war überhaupt passiert?

Ich hatte mit PHP ein Objekt über ein Array gelegt und das Interface "Iterator" implementiert um mit einer foreach()-Schleife direkt an die Inhalte des Arrays ranzukommen. Später dann wunderte ich mich, dass ich in einer Schleife immer nur das erste Element aus dem Array geliefert bekam und die anderen stillschweigend verschwanden.

Eigentlich lag die Lösung immer schon direkt vor meiner Nase, denn schon vorher hatte ich mich gewundert, dass wenn ich während der Schleife das aktuelle Element aus dem Array entferne, das nächste übersprungen wird. Eigentlich ganz einfach: Der Zeiger der foreach()-Schleife bleibt an der gleichen Position, nur die Elemente rutschen beim Löschen von hinten nach. Dementsprechend sollte man ihn nach dem Löschen mittels prev() zurück bewegen, bevor die foreach()-Schleife ein next() triggert. Dementsprechend ahnte ich schon, dass es nicht so ganz einfach ist mit meinem Objekt das exakt selbe Verhalten eines klassischen Arrays nachzustellen.

Aber warum lieferte mir die genannte Schleife nur noch ein Element aus einem Array mit mehreren Elementen?
Recht einfach: Mein Array-Objekt hat genau einen Zeiger auf die aktuelle Position im Array. Verschachtelt man nun ein paar foreach()-Schleifen, so entsteht hier ein heilloses Chaos und das Ergebnis wird niemals das erwartete sein.

Die ernüchternde Lösung meines Problems war dann schlichtweg ein IteratorAggregate und somit das Kopieren des Arrays für jede foreach()-Schleife. Ich kann mir gerade Szenarien vorstellen, wo auch das vermutlich schief gehen würde, allerdings sind die mir noch gar nicht untergekommen und ich wüsste ehrlich gesagt auch gar nicht, wie sich da ein normales Array verhält.

Hauptsache es tut für den Moment

Eigentlich ist es ja schon recht lange her, das ich über ein paar Fortschritte bei unserer Python-Implementierung geschrieben habe. Das Projekt war auch zugegebenermaßen auch etwas ins Stocken geraten, da ein paar Aufgaben anstanden, die aus wirtschaftlicher Sicht interessanter waren.

Das ging soweit, dass ich zwischenzeitlich gar nicht mehr wusste, dass die Schnittstelle gar kein CGI mehr spricht, sondern auf WSGI umgestellt wurde. Auch war mir gar nicht mehr bewusst, dass wir schon erste Geh-Versuche mit Ruby als weitere Skripting-Sprache gemacht hatten. Irgendwie ist nun abder doch wieder leben in die Sache gekommen.

Letzte Woche habe ich aus beiden Projekten den FastCGI-Code herausgeschnitten und eine abstrahierte Schicht zwischen Webserver und Skripting-Sprache geschaffen, die insgesamt leichter zu warten und etwas performanter als ihr Vorgänger scheint. Sehr schön
Das Problem, dass Kunden nicht beliebige Programme auf den Servern ausführen sollen, und ihnen auch der Blick in manche Verzeichnisse von vorne herein aus Prinzip verwehrt sein soll (vgl. PHP's open_basedir) ist auch schon angegangen worden - in Form einer lustigen kleinen Bibliothek, die einfach die (f)open's und exec's überlädt und entsprechend beschneidet.

Sowohl beim Überladen wie aber auch beim Abgreifen der Ausgabe eines Skriptes sei gesagt: Python arbeitet gerne mit fopen, d.h. man kann auch die Standard-Ausgabe jederzeit mit Cookies umleiten. Ruby hingegen greift auf das näher am Kernel liegende open zurück und holt sich von jedem FILE-Handle die entsprechende Deskriptor-Nummer. Wer hier eingreifen will muss tricksen - tut auch die abstrakte FastCGI-Schicht.

In beiden Fällen stehen eigentlich nur noch ein paar Tests bzgl. Performance und Ausfallsicherheit an. Viel schwieriger sind da aber dann andere Fragen, zum Beispiel werden Python-Skripte meistens per SSH installiert oder brauchen eine Shell - sowas bieten wir ja erst einmal konsequent nicht an. :-/

Seit gestern haben wir einen sog. Push-Dienst bei uns in der Sandbox, genauer genommen ist es etwas, was eine gewissen Kompatibilität mit Exchange und ActiveSync herstellt.

Irgendwie schon ein wenig gruselig, wenn ich aber auf meinem Handy meine Mailbox auf den Typ "Exchange" ändere funktioniert das oberflächlich ganz gut. Unter der Haube sieht es aber für meinen Geschmack recht grauenhaft aus: Es fängt bei der Definition "Push-Dienst" an. So wie ich die Technik verstanden habe ist das mehr ein Pull- als ein Push-Dienst. Selbiges meint auch das Zugriffsprotokoll des Servers auf dem wir den Dienst bereitgestellt haben - eine Anfrage reiht sich dort an die andere und bettelt den Server förmlich an, dass doch bitte irgendwas passiert sein soll. Da es "nur" ein Add-On für unseren IMAP-Server ist, sieht das Log dort entsprechend aus, denn jede Anfrage an den Push-Pull-Dienst generiert ein Login auf dem Mailserver.

"Technologien" (ich schreibe es in Anführungszeichen, weil der Begriff dafür echt zu groß ist) wie IMAP IDLE finde ich viel schöner: Der Client macht genau eine Verbindung auf, hält diese offen und bittet den Server "Sag mir kurz bescheid, wenn eine neue E-Mail da ist oder sich irgendwas tut". Auf mobilen Endgeräten mag es schon mal zu Verbindungsabbrüchen kommen, aber dann kann man die Verbindung ja wieder aufbauen. Der Exchange-ähnliche Dienst tut das ja auch, mutet da aber eher wie ein BOSH-Client mit weniger Funktion an. Zugegeben: Die BOSH-Entwickler behaupten mit ihrem Protokoll in wiedrigen Umgebungen besser Verbindungsabbrüche abfedern zu können als jeder andere, aber das geht gerade entschieden zu weit und tut hier nix zur Sache.

Meine ersten Erfahrungen waren nun also irgendwie negativ und sehr langsam - wenngleich auch irgendwie stabil. Dennoch bin ich irgendwie abgeneigt den Dienst als offizielles Feature zu erwähnen - hat denn irgendwer Interesse an einer ActiveSync-Schnittstelle zu seiner Mailbox (ohne Kontakte und Kalender)?