HTTP-Server + Python + DB als Bundle für Windows?

[Nico D.]

Warum nutzt ihr nicht einfach CGI-Skripte? Solche koennt ihr auch in C schreiben, wenn's genehmer ist.

[Shade Of Mine]

heini schrieb:

Warum nutzt ihr nicht einfach CGI-Skripte? Solche koennt ihr auch in C schreiben, wenn's genehmer ist.

Trollpost?

@scrontch:
django ist ein richtiges Framework und kein CMS. Es hat ein paar CMS-like features, aber die muss man nicht nutzen.

Du kannst es also definitv auch für ein Browser Spiel verwenden (obs natürlich die beste Wahl ist, musst du selber entscheiden).

[Nico D.]

Noe, war schon ernst gemeint.

[Shade Of Mine]

heini schrieb:

Noe, war schon ernst gemeint.

CGI ist eine furchtbare Technik. Das sollte man nie nutzen.
Denn bei jedem Request wird ein neuer Prozess gespawnt. Das skaliert total schlecht...

fastCGI bessert die Sache etwas, aber wirklich Sinnvoll sind nur Server Module - wo oben keine extra Prozesse gestartet werden muessen. Es gibt zB auch fuer C++ application Server, zB tntnet. Aber kompilierte Sprachen sind was das deployen betrifft stark limitiert. Du kannst nicht einfach lokal etwas testen und dann auf den Server spielen. Du musst auf viele Faktoren aufpassen und wenn du Pech hast sogar crosscompilen (was meistens eklig ist).

Weiters ist es oft ein Problem dass man das Projekt nicht selber hosten kann sondern es vom Kunden gehostet wird. Da sind solche Anforderungen wie zB CGI oder bestimmte Applicationserver natuerlich eher schlecht.

etc. etc.

Alles in allem: C++ Programme fristen aus gutem Grund im Netz ein Nischen dasein.

[Nico D.]

Also wenn's verdammt schnell sein muss und vorgefertigte Sachen wie PHP eher schlecht sind, gibt es noch die Moeglichkeit auf alternative Webserver zurueckzugreifen. Nachteil ist, man muss wirklich alles selbst schreiben und Vorteil ist natuerlich die Performance und u. U. die Sicherheit.

Ich will mir z.B. irgendwann mal (ich muss mich aber noch etwas mehr mit Shellscripting befassen) SWS antun und das weiterentwickeln, inkl. CMS, also auch mit dynamischen Inhalten. Aber das stuende noch in den Sternen.

Was meinst du: Ob ein Shellscript alleine schneller ist als Apache + Module + PHP oder Perl, wenn's denn richtig geschrieben ist (Voraussetzung Nr. 1 in Sachen Performance)?

[Shade Of Mine]

Wichtiger als performance ist skalierbarkeit.
Schneller als apache bist du bald... Skalierbarkeit ist das wichtige. Apache ist zb ein universalwerkzeug - der kann alles. Nicht am besten, aber dafuer ist einfach alles machbar.

[Nico D.]

Aber dann verstehe ich wiederum nicht ganz, warum ihr ueber PHP meckert. Nicht falsch verstehen -- mich interessiert nur, was euch daran stoert.

[scrontch]

Weil http://maurus.net/resources/programming-languages/php/ :p

[Shade Of Mine]

heini schrieb:

Aber dann verstehe ich wiederum nicht ganz, warum ihr ueber PHP meckert. Nicht falsch verstehen -- mich interessiert nur, was euch daran stoert.

Die Sprachdesigner von PHP sind absolute Vollidioten.
Klingt hart, ist aber so. Allein die Syntaxdefinition ist Schrott.
Von dem Rest rede ich ja garnicht erst.

PS:
der Rest ist super, nur die Coreentwickler von PHP, also die die Designentscheidungen treffen, die sind wirklich das unfaehigste was es gibt Man kann mit denen nichtmal vernuenftig reden. Es wird immer auf die naechste PHP Version verwiesen...

[nman]

Shade Of Mine schrieb:

Nicht am besten, aber dafuer ist einfach alles machbar.

Aber durchaus nicht alles einfach.

Für Proxying zB. ist Apache eine Katastrophe. Für Setups mit vielen VMs ist das aber durchaus wichtig. Was mit nginx völlig trivial ist, ist mit Apache ein mehrstündiges Hackfest, an dessen Ende dann doch nicht alles brauchbar läuft.

Natürlich hast Du mit Deinem Post trotzdem Recht, sinnvoller als irgendwas selbstgebasteltes als CGI-Skript ist praktisch alles.

[Shade Of Mine]

nman schrieb:

Für Proxying zB. ist Apache eine Katastrophe. Für Setups mit vielen VMs ist das aber durchaus wichtig. Was mit nginx völlig trivial ist, ist mit Apache ein mehrstündiges Hackfest, an dessen Ende dann doch nicht alles brauchbar läuft.

Interessant. Hab sowas noch nie aufgesetzt, deshalb bin ich da jetzt komplett blank.

Wo genau hat der apache da seine Probleme? Bis jetzt war es naemlich immer so, dass ich alles was ich wollte relativ einfach mit apache umsetzen konnte... Aber wie gesagt, sowas habe ich auch noch nie gemacht...

[scrontch]

Zurück zum Thema:
Dango IS IT!
Sieht sehr schön aus, super dokumentiert, und alles läuft bis jetzt einwandfrei und auf Anhieb. (Im Gegensatz zu der TurboGears und Pylons Frickelware).

[nman]

Shade Of Mine schrieb:

Wo genau hat der apache da seine Probleme? Bis jetzt war es naemlich immer so, dass ich alles was ich wollte relativ einfach mit apache umsetzen konnte... Aber wie gesagt, sowas habe ich auch noch nie gemacht...

Ich kann Dir das jetzt nicht mehr aus dem Stegreif genau sagen, aber das Problem war, damals in etwa folgendes:

• Apache als Proxy für mehrere Webserver in VMs.
• Einer der Webserver war eine Multiinstanz-Installation von Wordpress.
• Auf dem Wordpress-Server wird nach URLs dispatched.
• Dem Frontend-Apache zu sagen, dass er die entsprechenden Anfragen ans Wordpress an den Server mit der Private-Range-IP X.X.X.X schicken soll, dabei aber den Namen des Hosts nicht anrühren darf (weil das das Dispatching am Wordpress-Server komplett durcheinander bringt), ist absolut nontrivial.
• Wenn dann noch nur bestimmte URLs bestimmter Server umgeleitet werden sollen, oder POSTs woanders hingehen sollen als GETs (auch für viele größere Setups sonst interessant) wird es wirklich mühsam. (Schau Dir mal die Hacks in diversen Webframeworks an, die das umgehen sollen, zB. diese ganze VirtualHostBase bzw. VirtualHostRoot-Sache in Zope.)
• Mit nginx ist das alles unheimlich einfach, das Ding braucht extrem wenig Ressourcen und ist unheimlich performant.

Als Reverse-Proxy ist nginx wirklich toll und ich verwende ihn auch immer häufiger ohne Apache dahinter. Aber viel wichtiger: Weil das Proxying so unheimlich einfach und flexibel ist, kann man für jeden Zweck den Lieblings-HTTP-Server einsetzen und einfach weiterleiten wie man lustig ist. Dass damit einfache gemeinsame Caches direkt am Frontend-Server auch recht simpel sind, versteht sich von selbst.

(Angenehmerweise erspare ich mir damit mittlerweile übrigens auch ein paar HAProxy-Instanzen.)

[nman]

scrontch schrieb:

Zurück zum Thema:
Dango

Hast Du dafür auch ein hübsches gebundeltes Klickibunti-WAMP-Setup oder so gefunden? Wäre fein, wenn man interessierte Windows-User ggf. auf sowas verweisen könnte.

[scrontch]

Naja, also Python muss man schon noch selbst installieren.
Die Installation von Django geht dann aber von Python aus und reibungslos.
Als DB ist SQLite bereits bei Python 2.5+ mit dabei.
Auch kommt bei Django ein Debug-Webserver mit.
D.h. man kann direkt mit dem Programmieren loslegen und es funktioniert!
Vor Production-deployment muss man sich natürlich noch mal hinsetzen und eventuell auf ne andere DB und Production-Webserver umsteigen. Aber soweit bin ich noch nicht.
Wichtig war mir dass die Installation einfach ist und man schnell zur Sache kommen kann.
Ausserdem ist die API ansprechend und die Dokumentation sehr gut.