CGI.pm-Alternative

[pl]

Begründung fehlt.

Nana, ich hab das ausführlich begründet. Ergänzung: Es gab noch nie einen wirklichen Grund dafür, CGI.pm einzusetzen weil es

1. schon immer andere und zweckmäßigere Lösungen gab HTML zu erzeugen, nämlich über Templates,
2. schon immer andere und zweckmäßigere Lösungen gab, Response-Header zu erzeugen und zu puffern, nämlich über einen sinnvollen Einsatz einer objektorientierten Programmierung,
3. schon immer andere und zweckmäßigere Lösungen gab, die ganze Ausgabe in Richtung STDOUT zu puffern (auch OOP),
4. schon immer andere und zweckmäßigere Lösungen gab, Parameter zu parsen, ohne dass hierzu fünftausend Zeilen CODE (CGI.pm) kompiliert werden müssen.

Mit PSGI, Catalyst usw. werden ganz andere Ziele verfolgt. Was den CGI/1.1 Standard betrifft: Diese Schnittstelle ermöglicht, dass sämtliche Parameter eines HTTP-Request durch den Webserver hindurch einem nachgelagerten Prozess zur Verfügung stehen, das Gateway umfasst:

1. STDIN, STDOUT,
2. die Serverumgebung.

Man kann auch sagen, der Webserver wird dadurch transparent (durchsichtig). In Fakt schickt der CGI-Prozess (Perl, PHP) die HTTP-Response nach STDOUT, das Einzige, was hierzu bekannt sein muss, ist die Frage, ob der Webserver die Response-Header parst oder ob der CGI-Prozess selber für die Header zuständig sein soll (Non Parsed Header Scipts). Ansonsten ist einem CGI-Prozess der Webserver völlig Luft, der guckt durch den hindurch als gäbe es den gar nicht.

PSGI beschreibt lediglich eine andere Art und Weise des Zugriff auf die Serverumgebung.

MfG