WSGIarea online

mitsuhiko · Montag 31. Oktober 2005, 13:53

So. Ich hab die Schnauze voll gehabt. Es gibt in der Tat keine Webseite, die nicht in irgendeiner weiße was mit WSGI zu tun hat. Vom PEP333 mal abgesehen.

Damit soll jetzt Schluss sein

auf http://wsgiarea.pocoo.org werde ich jetzt solche Dinge sammeln. Wer einen WSGI Wrapper / Middleware angelegt hat kann es dort gerne hosten lassen.

joe · Montag 31. Oktober 2005, 15:56

blackbird hat geschrieben:Damit soll jetzt Schluss sein

Ich weiß nciht, worum es inhaltlich geht. Wollte nur darauf hinweisen, daß die seiten offensichlicht IE-*anti*optimiert sind. Hellgraue boxen oben aus dem menu, die beim firefox wohl richtig plaziert sind, tauchen beim ie irgendwo auf und verdecken den content.
joe

henning · Montag 31. Oktober 2005, 17:16

Wenns es einen Browser gibt *gegen* den man optimieren darf, dann ist es wohl der IE ,-)

joe · Montag 31. Oktober 2005, 17:24

henning hat geschrieben:Wenns es einen Browser gibt *gegen* den man optimieren darf, dann ist es wohl der IE ,-)

Best viewed with !IE

joe

mitsuhiko · Dienstag 1. November 2005, 09:48

Hey. Ob das Zeug jetzt unter IE läuft oder nicht war mir herzlich egal. Das Ding ist valid HTML4.0 (von einem kleinen moin1.5 bug abgesehen) und CSS2.0. Wers darstellt - gut.

Wie auch immer. Es geht hier um das Wiki als solches, wobei ich mich freuen würde, wenn dem Ding auch jemand etwas Content gibt.

henning · Dienstag 1. November 2005, 13:43

Wenn jemand ein Debian+Gentoo packages findet/fertigmacht, die mir WSGI für mod_python geben, bin ich gerne bereit, damit rumzuspielen und die Erfahrungen in Tutorials fliessen zu lassen

mitsuhiko · Dienstag 1. November 2005, 15:58

henning hat geschrieben:Wenn jemand ein Debian+Gentoo packages findet/fertigmacht, die mir WSGI für mod_python geben, bin ich gerne bereit, damit rumzuspielen und die Erfahrungen in Tutorials fliessen zu lassen

Ich mache gerade ein Package, in dem ich alle Wrapper einheitlich zusammenfasse. Dann sollte ein "from wsgi.wrappers.mod_python import WSGIServer" reichen um einen Wrapper zu bekommen. Da kann ich ja dann ein egg für machen

jens · Mittwoch 2. November 2005, 08:10

Irgendwie verstehe ich noch nicht wirklich was WSGI überhaupt sein soll... Soll es eine Ebene zwischen Programm und CGI, fastCGI, mod_python sein? Also das das CGI mit jedem Unterbau ohne Anpassung funktioniert?
Allerdings hat es kein Session-Management, wobei zumindest mod_python dafür was fertiges bietet.
Ich hätte erwartet das WSGI das weiter reicht und bei pure CGI halt was eigenes bieten und bei allen Varianten ist es für das CGI-Programm gleich zu handhaben...

henning · Mittwoch 2. November 2005, 08:35

Hmmm... das wär doch mal ein sinnvolles Projekt oder?
Also ein Session-Management-Layer, der das von mod_python durchreicht und auf den anderen Plattformen halt selbst implementiert.
Der sollte dann auch ruhig "unbhängig" von WSGI sein, weils ja auch Anwendungen gibt, die kein Session-Management brauchen.
Aber ich glaube, es gibt auch Erweiterungen zu WSGI also müsste man erstmal gucken, b nicht schonmal jemand die Idee hatte.

jens · Mittwoch 2. November 2005, 08:44

Naja, für PyLucid mußte ich mir ein Sessionhandling selber schreiben. Ich denke das haben schon viele andere auch gemacht. Wobei ich damals kein anprechendes gefunden hab.

Ich weiß nicht wie mod_python's Version funktioniert und bietet. Aber vielleicht ist es garnicht viel mehr als meine Geschichte und man könnte meins dafür umbauen...

@blackbird: Wie willst du das in pocco regeln?

mitsuhiko · Mittwoch 2. November 2005, 16:03

Jens hat geschrieben:Irgendwie verstehe ich noch nicht wirklich was WSGI überhaupt sein soll... Soll es eine Ebene zwischen Programm und CGI, fastCGI, mod_python sein? Also das das CGI mit jedem Unterbau ohne Anpassung funktioniert?

Exakt. Läuft auf allem wo es Wrapper gibt. Ich hab jetzt einen für mod_python und für CGI geschrieben, von den flup packages hab ich für FastCGI, AJP und SCGI.

Jens hat geschrieben:Allerdings hat es kein Session-Management, wobei zumindest mod_python dafür was fertiges bietet.

Und genau deswegen gibt es die Middlewares. Ich hab aus den flup packages die gzip und die Session Middleware. Dann noch von mir eine Google Highglighter, Debug und Cookie Middleware.

Jens hat geschrieben:Ich hätte erwartet das WSGI das weiter reicht und bei pure CGI halt was eigenes bieten und bei allen Varianten ist es für das CGI-Programm gleich zu handhaben...

Wenn du meinst, dass man von mod_python den Session Handler übernimmt für CGI Anwendungen ist das der falsche Weg. WSGI macht es schon richtig.

henning hat geschrieben:Hmmm... das wär doch mal ein sinnvolles Projekt oder?
Also ein Session-Management-Layer, der das von mod_python durchreicht und auf den anderen Plattformen halt selbst implementiert.
Der sollte dann auch ruhig "unbhängig" von WSGI sein, weils ja auch Anwendungen gibt, die kein Session-Management brauchen.
Aber ich glaube, es gibt auch Erweiterungen zu WSGI also müsste man erstmal gucken, b nicht schonmal jemand die Idee hatte.

Braucht man nicht, da es schon eine Session Middleware für WSGI gibt. Und die ist ausgezeichnet.

jens hat geschrieben:@blackbird: Wie willst du das in pocco regeln?

Und nochmal. Mit der WSGI Session Middleware

Meine WSGI Sammlung gibt es unter http://trac.pocoo.org/browser/wsgi oder direkt als SVN repo unter http://trac.pocoo.org/repos/wsgi

mitsuhiko · Mittwoch 2. November 2005, 16:07

Nochwas bevor ich es vergesse. Ich hab dem Author von flup von dem ich vieles übernommen habe eine Mail geschickt, ob wir unsere Projekte nicht fusionieren. Bin gespannt, was rauskommt.

mitsuhiko · Donnerstag 3. November 2005, 14:46

UPDATE: wsgiarea ist jetzt kein WSGI wiki mehr, sondern ein vorläufiges wiki für meine wsgi tools

jens · Donnerstag 3. November 2005, 21:50

Noch ne Frage...

WSGI muß man wahrscheinlich richtig installieren, oder??? Somit fällt es für einfache WebSpace/Python/CGI Lösungen flach, wenn es der Provider nicht installiert hat, oder?

Unter http://wsgiarea.pocoo.org/RunningWsgiApplications hast du ein paar Beispiele... Für mich sieht es irgendwie so aus, als wenn WSGI selber einen http Server darstellt 'WSGIServer(app).run()', oder sehe ich da was falsch???

mitsuhiko · Donnerstag 3. November 2005, 21:53

jens hat geschrieben:WSGI muß man wahrscheinlich richtig installieren, oder??? Somit fällt es für einfache WebSpace/Python/CGI Lösungen flach, wenn es der Provider nicht installiert hat, oder?

Muss man nicht und das ist ja auch das Feine. Für die Beispiele dort braucht man nur mein WSGI package und das kann man ja einfach in das Anwendungsverzeichnis hochladen.

jens hat geschrieben:Unter http://wsgiarea.pocoo.org/RunningWsgiApplications hast du ein paar Beispiele... Für mich sieht es irgendwie so aus, als wenn WSGI selber einen http Server darstellt 'WSGIServer(app).run()', oder sehe ich da was falsch???

Siehst du falsch

WSGIServer ist ein Wrapper. Beispielseweise zu CGI, mod_python... der ist ganz einfach aufgebaut und tut nichts anderes als eine Anwendung zu starten.

Für mod_python beispielsweise ist es noch leichter. Da kann man das Ganze einfach mit einer richtigen .htaccess starten.

jens · Freitag 4. November 2005, 07:50

Vielen dank für die Info...

In dem Fall, sollte ich mir das ganze auch mal ansehen

henning · Freitag 4. November 2005, 08:42

@blackbird: Kannst du schon ne Prognose abgeben, wann dieses egg fertig sein wird? Hätte nämlich eh größere arbeiten anstehen dann könnte ich in dem Zug auch auf WSGI umstellen.

Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.

Bei CGI wird ja glaub ich alles immer neu geladen. Bei mod_python ist das nicht grundsätzlich der Fall, da hängt die Lebensdauer ja von den Apache-Threads etc... ab (u.U. werden sie dogar erst beim apache-neustart neu geladen!).

Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?

mitsuhiko · Freitag 4. November 2005, 10:28

henning hat geschrieben:@blackbird: Kannst du schon ne Prognose abgeben, wann dieses egg fertig sein wird? Hätte nämlich eh größere arbeiten anstehen dann könnte ich in dem Zug auch auf WSGI umstellen.

Geplant ist das Egg mit allem drum und dran spätestens Ende November fertigzustellen.
Momentan weiß ich noch nicht, ob die die sourcen von flup auch wirklich in das Paket übernehmen kann, warte noch auf Antwort vom Author.

henning hat geschrieben:Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.

Ich lade die WSGI Anwendung im Falle von mod_python für die htaccess.

Code: Alles auswählen

            SetHandler python-program
            PythonHandler wsgi.wrappers.modpy::handler
            PythonOption application my_application::app
        </Directory>

Die Anwendung wird vom WSGI Wrapper dann mit hilfe des apache modules geladen. Details gibts hier

henning hat geschrieben:Bei CGI wird ja glaub ich alles immer neu geladen. Bei mod_python ist das nicht grundsätzlich der Fall, da hängt die Lebensdauer ja von den Apache-Threads etc... ab (u.U. werden sie dogar erst beim apache-neustart neu geladen!).

Jup. Ein mod_python Thread lebt ewig, daher auch sehr schnell. Zu Enwicklungszwecken würde ich deswegen immer mit einem CGI Wrapper arbeiten und mod_python erst im Produktivsystem einsetzten.

henning hat geschrieben:Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?

Tun sie auch

henning · Freitag 4. November 2005, 11:06

Sorry, ich habe immer noch nicht vertanden, wie das jetzt ist.
Untergräbt der WSGI-Wrapper jetzt nun diese Eigenschaft von mod_python oder nicht?

Ganz banal gefragt:
Wenn ich bei einem request eine Modulglobale Variable setze, ist sie dann beim nächsten Request noch da oder nicht?

Bei mod_python war sies ja (zumindest wenn der apache-thread so lange gelebt hat). Bei CGI wäre sie's grundsätzlich nicht. Oder hast du versucht mir zu sagen, dass man seinen Code halt für beide Fälle schreiben muss? (Im Grunde kann ich mich ja auch in mod_python nicht drauf verlassen, dass zu einem bestimmten Zeitpunkt der Thread noch lebt und muss ggf. davon ausgehen, dass alles neu geladen worden ist)

mitsuhiko · Freitag 4. November 2005, 11:22

henning hat geschrieben:Sorry, ich habe immer noch nicht vertanden, wie das jetzt ist.
Untergräbt der WSGI-Wrapper jetzt nun diese Eigenschaft von mod_python oder nicht?

Natürlich nicht.

henning hat geschrieben:Ganz banal gefragt:
Wenn ich bei einem request eine Modulglobale Variable setze, ist sie dann beim nächsten Request noch da oder nicht?

Natürlich ist sie noch da. Bei CGI wird sie halt immer neu erstellt, bei mod_python überlebt sie.
Wenn du selber wissen willst, ob sie überlebt oder nicht, musst du nur im Environ nachsehen: (environ['wsgi.run_once'])