Mailinglisten-Archive |
Ulf Seltmann schrieb: > Sebastian Mendel schrieb: >> opcache? was büßt man da ein? ich dachte da büßt man eh schon wenn man CGI >> nimmt? > bei CGI ja, bei FastCGI nein. ahso, läuft bei FastCGI ähnlich wie bei mod der PHP Prozess ständig, oder so was ähnliches? >> 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. >> sollte ein Anwendung nicht so geschrieben sein das mit allen PHP >> Einstellungen zurecht kommt? also keine angepassten Konfigurationen >> (getrennte php.ini) nötig ist? > Wenn ja, wären wahrscheinlich die Hälfte aller Fragen hier überflüssig. Du meinst wenn es so wäre, also alle Anwendungen so geschrieben sind, ich meinte ja aber es sollte so sein, das es nicht so ist, ist mir durchaus bewusst. Aber ich glaube auch nicht das die Hälfte aller Fragen hier in unterschiedlichen Konfigurationen begründet ist. Und überflüssig wären sie schon kaum, nämlich genau um diese ideal zu erreichen. >> 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. >>> 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? > Warum interessiert dich dieser Thread hier überhaupt? Scheinbar sollte ja > niemand Probleme mit verschiedenen PHP-Versionen und -Einstellungen haben. Zumindest wäre dies möglich für den Anwender (bzw. das Live-System), der Entwickler muss sich natürlich damit rumschlagen, wie soll er sonst testen. > Aber ich glaube, du hast noch nicht viel mit Adminstration von > Hostingumbebungen zu tun gehabt, ansonsten wüsstest du, was alles > schiefgehen kann, und dass alles, was schief gehen kann auch schiefgeht. Murphys Gesetz ist mir schon bekannt. > 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? -- Sebastian
php::bar PHP Wiki - Listenarchive