Marco Mariani ha scritto:
Limitato, in che senso? Nel senso di "sicuro" ? :-
più che sicuro, JSON trasporta solo parti di JS e non può fare, ad
esempio, questo:
http://devpro.phpsoft.it/php_serializer/
Trasportare una classe da e verso il server.
Gli array in JS sono anche associativi (Array extends Object, quindi non
esiste un vincolo sull'uso di array come associativi), molto simili a
quelli PHP, improponibili ad esempio in Python (infatti la serializer
sceglie se trasportare una dict o una list in automatico, cosa che il
progetto ufficioso della python php serializer non fa), ma come per php
può trasportare classi Python e sfruttarle, se presenti, anche in
JavaScript, o crearle runtime e sfruttarle come oggetti normali.
In poche parole a parte la fagianata della strlen di php (numeri veri
solo senza encoding diverso) il formato serializzato di php lo trovo
assolutamente più efficace di quello JSON ed in php la fatica di
conversione non è delegata al server (Pear, stra ottimizzata, stra lenta
lostesso) ma al client (comunque rapidissimo su decine di migliaia di
valori innestati o meno).
In python dovrei sfruttare una struct (della versione 2.5) oppure
leggermi qualcosa su PyRex o fare un modulo in C così da colmare il gap
in serializzazione / deserializzazione (ma su python non ha molto senso
abilitare la conversione in utf8 quindi sia il JS che il python in quel
caso sono rapidissimi).
Saluti,
Andrea Giammarchi
P.S. JSON-RPC basato su XML tende anche ad aumentare la banda in scambio
dati, serialize / unserialize ne prende poca in più di JSON normale (in
realtà in certi casi molta di meno non avendo la sfilza di \xAB per ogni
stringa unicode) e la serializzazione client mi sembra sia anche più
veloce di quella ufficiale JSON per JS, unserialize ovviamente non regge
il confronto, un eval post RegExp non ha equivalenti.
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
