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