[Python] mod_python ed il giusto handler

[Lawrence Oluyede]

> io non introduco niente ... la libreria lavora in background,
> l'introduzione del formato serialize di PHP è lo stesso identico
> concetto di JSON, esistono versioni di serialize / unserialize per quasi
> lo stesso numero di linguaggi eh ... non è una novità e permetterebbe a
> tale libreria di lavorare su più linguggi server invece che su uno solo,
> tutto qua

Perchè non usi semplicemente XML-RPC allora se ti interessa il cross language?

> e hai detto niente ... visto che lo stato ti permette di ricostruire,
> sul client se presente, o sul server, se presente, un'istanza aggiornata
> dell'oggetto.

Beh se ti interessa passera dati rilancio xmlrpc che più standard non
si può :-)
Complicato capire cosa vuoi fare :P

> > In python pero` gli oggetti non sono altro che dizionari, allora
> > perche` complicarsi la vita per scrivere tutto sto popo` di roba
> > quando basta saper trasmettere dizionari?
> perchè i dizionari non sono istanze di oggetti ma appunto dizionari ?

A me pare che in Python un dizionario sia un oggetto, ignoro cosa sia
in PHP ma ti posso giurare che in Python un dizionario *è* un oggetto.
Ha un tipo (dict), ha una sintassi literal, ha dei metodi, uno stato.
E' un oggetto.

> perchè non puoi usare o inviare classi client / server e gestirne lo stato ?

A te interessa solamente spostare informazioni dal pc X al pc Y. Passi
"dati", poi cosa ne fai è affar tuo

> significa che ogni client si gestisce la sua istanza delel sue classi,

E questo mi sembra la cosa più normale del mondo dato che gli oggetti
su un client non sono quelli sull'altro.

> significa un approccio completamente OO anche sul client, usando anche
> classi e non solo {}

Mi sa che non hai approfondito molto Python prima di imbarcarti in
questo progetto perchè è scritto pure nel tutorial che i dizionari
sono oggetti.

> prima dici del po po di roba, poi mi parli dell'inutilità di inviare
> stati di oggetti, quidi implementeresti un metodo dedicato che a seconda
> della classe assegna eventualmente quello o quell'altro parametro
> all'istanza dell'oggetto ??? ... io invio istanze, non devo fare altro,
> inutile eh ? per me non lo è mai stato, sarò io che ho i paraocchi bucati ?

Ma quanta roba devi passare da un server a un client, si può sapere?
Sembra che tu stia gestendo una foresta di dati supercomplessi di
megabyte di stato.

> si, pazienza, tanto dato i tuoi discorsi lavori solo con dizionari,
> chissà quali "stratagemmi" per ricreare i metodi, stratagemmi inutili
> quando puoi inviare già un oggetto con quel metodo, poi l'invio di più
> oggetti non ne parliamo

Sei al corrente vero che non c'è praticamente nessuna differenza tra
passare una oggetto senza metodi (quindi solo lo stato) e il
dizionario del suo stato?

> Stessa classe, stesso stato, metodi uguali con o senza lo stesso nome
> con possibilità di usare operazionidifferenti a seconda
> dell'utilizzatore, client o server.

Mi sfugge perchè il server dovrebbe avere le stesse classi che ci sono
su N client. In tutta questa discussione il vero problema secondo me è
che non si è capito cosa stai realmente cercando di fare, a parte
tutti i termin di passare oggetti in giro. Cosa cerchi di ottenere in
soldoni?

> > Perche` e` assurdo che la stringa di byte (ovvero una stringa di testo
> > codificata in utf-8) debba ritornare i caratteri e non la lunghezza?
> e chi l'ha mai detto ? Io ho solo detto che è una pecurialità di php e
> php "soltanto" ed è la causa del rallentamento in serializzazione /
> unserializzazione con JS o gli altri linguaggi quando devi interagire
> con il formato serializzato di php abilitando il supporto UTF-8

Semplicemente perchè PHP ha un pessimo supporto per ciò che non è ASCII

> Il nesso è la portabilità della lib, ma a quanto pare avete già
> l'onnipotenza in materia e quindi una lib che con una sola scrittura del
> client si porta anche in Python, oltre che PHP e C# non vi interessa.

Non è che non interessa. E' che, almeno io, non vedo il problema che
stai cercando di risolvere. Tutto qui. Non mi sembra di aver detto di
essere onnipotente o cose del genere. Ho tenuto un tono
tranquillissimo proprio perchè mi sembra che tu stia inventando
l'acqua calda e ci sono passato anche io in passato.

> Strano, nell' era del "web js & ajax" avere librerie da non dover
> riscrivere anche per il client dovrebbe muovere l'interesse collettivo,
> proverò con gli altri linguaggi, abbandono il porting per Python ? Visto
> che tutto è inutule e che non si capisce niente dell'intento o le
> potenzialità della libreria devo proprio aver cannato linguaggio ...

Beh se tu stai reimplementando JSON non capisco perchè dovrebbe
esserci un interesse collettivo per una cosa che è già una RFC tra le
altre cose. Magari proponi a loro di migliorare le cose che non ti
piacciono, no?

> Che ne dici di evitare di valutare ancora prima di conoscere ?

Sono tutt'orecchi, cosi finalmente capisco cosa stai realmente
cercando di implementare. Perchè questi ultimi post mi sono sembrati
un pò confusi

> si, non è compatibile con le stringhe UTF-8 , invia liste, tuple e dict
> e ritorna sempre e solo dict, non invia ne riceve Classi.

Cavoli, i dict SONO classi, almeno in Python. Ma anche in JS

> Tra l'altro il tizio della serialize "che esiste già" mi ha già fatto i
> complimenti ed ha detto che quanto prima avrebbe aggiornato il suo sito
> per segnalare la variante.

Non metto in dubbio che la cosa tu hai implementato abbia un senso e
una ragione di esistere ma mi pare la risoluzione di un problema che
ha PHP, o mi sbaglio?

-- 
Lawrence
http://www.oluyede.org/blog