[Python] mod_python ed il giusto handler

[Andrea Giammarchi]

Valentino Volonghi aka Dialtone ha scritto:
> Non e` mai una buona idea questa ed e` colma di vari pericoli 
> concernenti la sicurezza.
usato male anche JSON è pericoloso, tanto quanto qualunque chiamata via 
HTTP ...


> Una soluzione a questo tipo di lavoro e` definire bene un protocollo 
> per lo scambio di oggetti dove sia da python che da javascript vengono 
> scritti serializer/unserializer per ogni nuovo oggetto che ha la 
> necessita` di essere trasportato.
già definito dal PHP, formato serialize / unserialize di php


> A conti fatti questo e` abbastanza inutile perche` nessuno ha davvero 
> bisogno di scambiare oggetti python con javascript vista sia l'enorme 
> differenza di capacita` (javascript essendo sandboxed non puo` fare un 
> milione di cose tipo aprire file sul filesystem, pertanto non ha senso 
> serializzare una classe che ha un fd aperto ad esempio).
bisogna avere un Q.I. molto basso per pensare di trasportare un oggetto 
che lavora su filesystem in javascript.
Detto questo, dite di apprezzare tanto l'astrazione e vi castrate con 
questa possibilità ?

Inviare un oggetto User, manipolarlo su ogni client, aggiornarlo e 
salvarlo sul db o su un cookie, ad esempio, credi sia così inutile sul web ?

Non parlo di new User().name e basta, parlo anche di metodi ben definiti 
anche sul client come un me.login() che se da un true autentica 
l'utente, programmazione ad oggetti client tanto quanto sul server, 
facile, sicuro, cos'altro dire ?


>
> Che JSON poi non sia il massimo e` anche vero ma scambiando oggetti 
> semplici comprensibili da javascript funziona benissimo e ci puoi 
> scrivere applicazioni enormemente complesse con poca difficolta`.
no, non puoi, se vuoi avere anche la possibilità di manipolare oggetti a 
polimorfismo variabile client / server (non so cosa abbia appena detto 
ma è l'unica cosa che mi veniva da dire).

Le classi e la OOP la conoscete molto bene e non capisco questo 
accanimento contro il trasporto di oggetti.



> Che significa numeri veri senza encoding diverso?
utf8 ... in php serializzare 'à' può produrre, in charset non UTF-8, 
s:1:"à"; .... in un charset UTF8 o con dati salvati in UTF8 produce 
invece s:2:"à"; .... il 2 non è la length della stringa, è il numero di 
bytes usati per essa. Questa caratteristica rallenta la riconversione in 
UTF8 ma solo col PHP, se JS è usato con Python o C# questa "features" 
non è necessaria, quindi nessun rallentamento.


> Il server non serializza e sinceramente la vedo dura trasmettere dei 
> dati su socket senza serializzare in qualche modo.
facciamo a capirci ... la classe Pear per "serializzare" e 
"deserializzare" JSON, per quanto ottimizzata, è un mostro di lentezza 
perchè deve fare un char by char con non so quante regexp per ogni 
stringa che incontra. La versione compilata non è quasi mai presente 
negli hosts e quindi usare quella classe è un suicidio per prestazioni e 
risorse.

serialize() ed unserialize() sono funzioni in-core, sempre presente, 
scritte in C, rapidissime .... ergo il server lavora 1/20 ed usa 1/20 
delle risorse ed è molto più veloce.
Stando a questo, usare serialize invece di JSON premette veramente di 
creare applicativi enormenente complessi capaci di gestire una "enorme" 
utenza.



> Quando il client trasmette serializza e il server deserializza e vice 
> versa.
> JSON comunque ha il vantaggio di avere il parser piu` veloce del mondo 
> lato client... Il browser che fa eval().
si, lo so, ma la PHP_Serializer ha tutti i tricks possibili per far si 
che non si noti la differenza tra le due versioni e delega comunque il 
compito al client, nel caso di PHP.



> Che hanno le struct della versione 2.5? E come le parsi lato 
> javascript? Puoi fare packing/unpacking di binari in javascript con 
> piu` facilita` che un eval?
non ho approfondito ma pare pseudo compilino e mettano in cache e siano 
più veloci di almeno un 20% rispetto le precedenti.
La facilità di un eval non mi interessa affatto quando il problema dei 
siti è sempre il server e raramente i calcoli sul client.


> Non mi e` chiaro cosa abbia a che fare Pyrex con questo.
Un modulo in C sicuramente più veloce del solo Python per fare una 
PHP_Serializer per quest ultimo che non sprechi troppe risorse .... cosa 
che ho già scritto, ma che non va per via di un.NET framework ...



> Non esistono stringhe unicode che possano essere trasmesse su un 
> socket. Il socket e` byte oriented e unicode no (non si possono 
> trasmettere stringhe senza che vengano codificate in qualche modo).
Parlavo di UTF-8, errore mio.

Andrea Giammarchi