Grazie delle delucidazioni,<br>credo che approfondirò adeguatamente wsgi.<br><br>ciao<br>IDM<br><br><div class="gmail_quote">Il giorno 27 luglio 2009 10.53, Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it">roberto@unbit.it</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Mon, 2009-07-27 at 09:26 +0200, Ivan wrote:<br>
<br>
><br>
><br>
> Quali vantaggi/svantaggi ci sono nell'utilizzare mod_python<br>
> anziché wsgi, con django ?<br>
> Il tutto su Linux con apache.<br>
><br>
> Walter<br>
><br>
<br>
</div>E' un discorso lungo e come al solito e' impossibile stabilire quale dei<br>
2 e' migliore. Provo a fartela il piu' facile possibile.<br>
<br>
Sono 2 approcci diversi con i loro pro e contro.<br>
<br>
WSGI e' uno standard, e' semplice, chiaro ed ha un solo obiettivo:<br>
rendere l'implementazione di una applicazione web indipendente dal tipo<br>
di webserver che risiedera' davanti. Stiamo parlando quindi di un<br>
protocollo non di una implementazione.<br>
<br>
mod_python invece e' una implementazione (simile a mod_php come logica<br>
di funzionamento), integra in apache un interprete python che si occupa<br>
di eseguire il codice richiesto.<br>
<br>
Ora, un bravo amministratore di sistema gia' si sentirebbe male al<br>
pensiero che il proprio webserver (che ricordo a tutti e' esposto al<br>
pubblico e quindi gia' di suo deve sostenere ogni tipo di attacco) venga<br>
"inquinato" da un nuovo modulo.<br>
<br>
A questo aggiungi che gli stai dicendo che il suo apache sara' ora in<br>
grado di eseguire codice di qualsiasi tipo (con i permessi di apache) e<br>
nella sua mente arrivera' la vocina del grillo parlante sysadmin che gli<br>
urla (con tanto di eco) "attenzioneeee stai introducendo una componente<br>
non deterministica in un server esposto al pubblicooooo....).<br>
<br>
Ora non voglio scatenare il panico ma se avete un webserver su cui fate<br>
eseguire script di altri sotto mod_php (o mod_python) ricordatevi che e'<br>
molto facile distruggere il vostro bel webserver. Indipendentemente da<br>
tutte le protezioni che il modulo possa includere.<br>
<br>
Questa e' la nota negativa di mod_python (qualcuno potrebbe aggiungere<br>
che si tratta di un modulo apache non molto utilizzato e quindi di per<br>
se' poco affidabile, ma su questa argomentazione non mi sento di<br>
esprimermi).<br>
<br>
Se pero' stai mettendo su un webserver con una sola applicazione python<br>
scritta da te l'equazione cambia e probabilmente il gioco VALE la<br>
candela. Almeno fin quando non decidi che apache (o Linux) ti fanno<br>
schifo e vuoi sostituirli.<br>
<br>
E' qui che WSGI ti da una mano. E' indipendente dal webserver (e<br>
ovviamente dal sistema operativo). Puoi spostare la tua app da un<br>
webserver a un altro (che supporti wsgi ovviamente) senza cambiare una<br>
sola riga di codice. Riconfiguri il webserver e sei operativo.<br>
<br>
Ma apache come comunica con una applicazione WSGI ?<br>
<br>
E' qui che entrano in gioco le implementazioni di server WSGI.<br>
<br>
Ci sono molti webserver wsgi scritti in python a cui le richieste<br>
vengono passate via http dal webserver (quindi un reverse proxy, piu'<br>
standard di cosi' si muore). Il webserver di CherryPy e' uno di questi.<br>
<br>
mod_wsgi per apache (di cui trovi una variante, sotto molti aspetti<br>
superiore, per nginx) puo' funzionare sia in maniera simile a mod_python<br>
(integrando l'interprete python in apache che si occupa di eseguire il<br>
modulo wsgi) o in modalita' "daemon" per cui viene generato uno o piu'<br>
processi (che possono girare con il loro uid) che si occupano di gestire<br>
le richieste che Apache gli passa attraverso un socket/pipe.<br>
<br>
Flup, e' un server WSGI che comunica con il webserver tramite<br>
FastCGI,SCGI e (udite udite) AJP.<br>
<br>
uWSGI (drin drin, pubblicita') e' un server WSGI in C che riceve le<br>
richieste da apache su socket UNIX tramite un semplice ed efficiente<br>
protocollo. Non fa della facilita' di utilizzo (come va di moda di<br>
questi tempi) il suo punto di forza, ma punta tutto sulle feuture e<br>
sull'affidabilita'.<br>
<br>
Ci sono altre decine di server (con i piu' svariati approcci), trovi<br>
l'elenco qui:<br>
<br>
<a href="http://www.wsgi.org/wsgi/Servers" target="_blank">http://www.wsgi.org/wsgi/Servers</a><br>
<br>
<br>
Ovviamente (punto non trascurabile) praticamente tutti i framework web<br>
in python (e molte applicazioni) sono compatibili wsgi. Ma e' anche vero<br>
che mod_python e' compatibile con qualsiasi cosa che sia scritta in<br>
python :)<br>
<br>
Cosa scegliere ? Io personalmente ho scommesso sull'approccio WSGI e<br>
come punto a suo favore posso aggiungere che nel mondo ruby (dove il<br>
deploy e' un totale incubo) si e' sviluppato Rack che e' pressocche'<br>
uguale a WSGI mentre mod_ruby e' stato praticamente relegato in un<br>
angolino buio e puzzolente.<br>
<br>
Il link che ti ha mandato prima Sandro e' sicuramente un ottimo punto di partenza.<br>
<font color="#888888"><br>
<br>
--<br>
Roberto De Ioris<br>
<a href="http://unbit.it" target="_blank">http://unbit.it</a><br>
JID: <a href="mailto:roberto@jabber.unbit.it">roberto@jabber.unbit.it</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it">Python@lists.python.it</a><br>
<a href="http://lists.python.it/mailman/listinfo/python" target="_blank">http://lists.python.it/mailman/listinfo/python</a><br>
</div></div></blockquote></div><br>