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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
