zzap -> twitter

Seit eben gerade funktioniert mein zzap-to-twitter Interface endlich (wieder). Die dummen Kommentare in meinem Badge kommen alle vom Testen.

Was ist daran jetzt neu?
Bis vor 2 Wochen hatte ich ja bereits eine funktionierende Verbindung. Die jetzige Lösung unterscheidet sich aber in einem wichtigen Punkt: Nebenläufige Programmierung. Das bedeutet, daß das normale Skript, welches der Nutzer per Webbrowser aufruft, alle Arbeiten, die möglicherweise mehrere Minuten in Anspruch nehmen können, nicht selber ausführt, sondern an ein anderes Skript weiterreicht und sich selber beendet, während im Hintergrund die zeitintensiven Tasks weiterlaufen. Das ist eine Voraussetzung, um ein Benachrichtigungssystem für externe Systeme betreiben zu können.

Wo war das Problem?
Die Aufgabe war klar, aber es gibt immer 100 verschiedene Wege zum Ziel. Die ersten Ideen gingen in Richtung einer Task-Queue, also einem ständig im Hintergrund laufenden Skript, daß nachschaut, ob eine neue Aufgabe anliegt. Davon bin ich schnell wieder abgerückt, weil diese Lösung Overkill wäre und außerdem Probleme bei vielen Hosting-Providern verursachen würde, die ständig laufende Hintergrundprozesse ausschließen.

Es musste also etwas einfacheres her: Der eigentliche Worker-Prozess muss direkt vom Webscript gestartet werden.

Üblicherweise macht man so etwas mit dem exec() – Befehl in PHP. Das funktionierte auch wunderbar sowohl auf meinen Entwicklungssystemen (jeweils einmal Windows, Apple OS X und Sun OS), aber ausgerechnet auf meinem Live-System war das Skript nicht zum Laufen zu bekommen. Den Worker direkt auf der Kommandozeile zu starten war kein Problem, nur über den exec-Befehl in einem Web-Skript startete er nicht – unabhängig von allen Dateiberechtigen und Pfadeinstellungen. Ich vermutete schon, daß der Provider diesen Befehl aus Sicherheitsgründen einfach gesperrt hat, aber ein einfaches echo exec(‘whoami’) zeigte völlig korrekt den Owner des Webservers an. Um es kurz zu machen: Der ganze Kram hat mich gut eineinhalb Wochen gekostet und gestern hatte ich die Nase voll.

Die Lösung, die ich jetzt verwende ist richtig “basic”: Das Worker-Skript wird per HTTP über CURL aufgerufen. Ganz ohne Hakeleien ging auch das nicht ab, aber nun läuft es erst einmal. Ob diese Lösung auch einen Load von 1000 remote-calls verkraftet, weden wir dann sehen, wenn das Protokoll zum Nachrichtentausch funktioniert. Für heute bin ich jedenfalls erstmal zufrieden.