Mailinglisten-Archive |
Sebastian Mendel schrieb: > ahso, läuft bei FastCGI ähnlich wie bei mod der PHP Prozess ständig, oder so > was ähnliches? genau. >>> oben bezeichnest du es als 'krank' durch Konfiguration Probleme zu lösen, >> Ich bezeichne es (aus Administratorensicht) als krank, _solch_ eine >> Konfiguration zu bewerkstelligen. Wenn du anderer Meinung bist, wie wäre >> es mit ein paar Argumenten? > > Wieso brauch ich Argumente es nicht als krank zu bezeichnen, versteh ich > nicht? ich sehe keinen Nachteil darin PHP einmal als mod und einmal als CGI > in einem Apache zu verwenden und wollte halt nur von dir wissen warum du es > anders siehst. Ich habe versucht es zu erklären, aber Erfahrungswerte lassen sich nur schlecht als Argumente einsetzen. >>> oh, mod ist also schneller als CGI, das spricht aber eher gegen CGI, oder? >> das einzige, was _für_ CGI spricht, ist Sicherheit zusammen mit suexec >> und das verzeichnisabhängige Umschalten der PHP-Version mittels >> .htaccess (und individuelle php.ini's). > > na ok, die zwei Sachen kannte ich bisher auch, es hatte sich nur so gelesen > als wenn es da wesentlich mehr gebe, und nichts für mod sprechen würde, > dachte halt nur ich hätte da was verpasst bsiher. Ich halte mittlerweile nicht mehr viel von mod_php. es lässt sich zwar schön leicht einrichten, aber von Sicherheit ist nicht viel übrig. CGI ist zu langsam, bleibt nur noch FastCGI, IMHO die beste Lösung. >>>> Environment-Variablen unterscheiden sich auch von CGI zu mod_php, was in >>>> der Programmierung erhebliche Schwierigkeiten machen kann. >>>> Mal von den PHP ausführenden Benutzern ganz abgesehen. >>> Programmiert man nicht eh so das es in beiden Umgebungen läuft!? >>> bzw. das Framework auf das man setzt. >> Hast du schon ein Framework mit "Interpreterweiche"? Ich nicht. > > Mit Interpreterweiche? Nein. Wozu sollte man sowas brauchen? > Nehmen wir z. B. mal phpMyAdmin, meines Erachtens läuft das doch auf allen > Konfigurationen, oder? Und was hältst du von Typo3? Leider muss ich mich damit herumschlagen mit dem Ergebnis, dass an vielen Stellen auf php_sapi_name() geprüft wird, was in vielen Umgebungen verschiedene Werte zurückliefert (SuSE,Debian,XAMPP) und entsprechend Pfade zusammenbaut. Sowas verstehe ich unter einer "Interpreterweiche" (in Anlehnung an den gebräuchlichen Begriff "Browserweiche", der Web-Designer immer einen Schauer über den Rücken laufen lässt ;) >> Kleines Beispiel: in PHP4 ist die Variable $_SERVER['SCRIPT_FILENAME'] >> bei CGI der Interpreter, bei mod_php ist es das PHP-Script. Bei PHP5 ist >> es für CGI und mod_php wieder gleich, nämlich das PHP-Script, aber es >> gibt eine neue Variable $_SERVER['ORIG_SCRIPT_FILENAME'], die den >> Interpreter enthält. > > yepp, und? dieses Problem umgehst du durch individuelle php.ini's??? > Das ist genau ein Argument dafür das Anwendungen mit allen Umgebungen > umgehen könne müssen weil du dieses Problem eben nicht durch individuelle > php.ini's umgehen kannst, oder? Richtig. Damit wären wir wieder bei der "Interpreterweiche". So etwas tun wir nicht. Unsere Testumgebung entspricht (weitgehend ;) der Live-Umgebung. Wenn sich die Live-Umgebung ändert, migrieren wir die Applikation (insofern nicht abwärtskompatibel) auf die neue Umgebung. ciao Ulf
php::bar PHP Wiki - Listenarchive