[Python] mod_python ed il giusto handler

[Andrea Giammarchi]

Valentino Volonghi aka Dialtone ha scritto:
> E questo come e` possibile? Puoi inviare solo ascii?
utf8_encode ... utf8_decode

> Inoltre se il tuo sogno e` tenere aggiornate le istanzi degli
> oggetti tra server e client vivrai una vita grama e ricca di 
> spiacevoli sorprese.
soprese ancora niente, di sogno ben poco visto che lo faccio da tempo



> Embe`? L'object system di javascript e` comunque diverso da quello di 
> python e
> comunque devi riscrivere la classe sia in python che in javascript.
ovvio, in python però puoi anche non farlo e gestire runtime classi JS 
ergo non scrivi sempre e comunque il codice 2 volte.
l'invio e la ricezione di oggetti, ribadisco, è un di più, non l'essenza 
della lib che fa tutto quello che fate voi oggi, ma da anche questa 
possibilità che a voi non interessa per alcun motivo (a me si)


> A parte che l'approcio completamente OO non significa nulla. Ma non 
> vedo come
> questo modo di serializzare de-serializzare oggetti possa far cambiare 
> l'approcio.
approccio a specchio, puoi gestie oggetti client e server allo stesso 
modo sul client come sul server


> Si. Faccio un esempio del codice javascript lato client su cui lavoro
> abitualmente visto che probabilmente quello di cui parlo e` piu` 
> complesso di
> quello che sembra: ....
troppo ...


> Io uso JSON e mi sembra di usare un approcio a oggetti piuttosto 
> spinto lato
> client. Giuro inoltre che potrei mostrarti una tonnellata di 
> javascript molto
> piu` complesso di questo che utilizza ancora JSON.
ne sono convinto, JSON è eccezionale, in PHP JSON è un ammazza risorse 
per via della lentezza orribile della conversione, PHP lo uso tuttora, 
non userei mai ne farei mai una libreria ajax per php con JSON di mezzo 
se non tramite il compilato che non è mai presente nei servers virtuali 
e non



> Il metodo lo devi scrivere comunque in javascript quindi questo non 
> c'entra niente.
scrivi una classe (funzione) fine, non devi poi rifare niente, ti 
ritrovi l'istanza malipolabile, inviabile, etc etc


> Lavori il doppio perche` il tuo modello e` enormemente piu` complesso 
> da gestire.
quello mio si, quello finale a livello di utilizzo non ha nulla di 
complesso, è a prova di niubbi, sai definire un dict statico di una 
classe ? (methodTable) sai fare interazioni avanzate in ajax con JS 
sapendo poco anche di JS.




> non puoi inviare metodi con la serializzazione ma solo lo stato quindi 
> i metodi
> devi comunque scriverli per cui non mischiare troppi argomenti.
invii uno stato che ricrea l'oggetto ergo invii oggetti e non devi fare 
altro per usarli come tali



> Come? E questo cosa ha a che fare col polimorfismo?
il polimorfismo non c'entrava niente , la frase era senza senso e commentata



> Cosa c'entra? Non puoi trasportare i metodi. Devi scriverli i metodi.
bene


> Permettimi ma non posso che dissentire, di semplice il modello non ha 
> nulla.
modello di cosa ?


> E` tremendo. Quindi io posso accedere a tutti gli oggetti che voglio lato
> client facendo quello che desidero attraverso quegli oggetti? 
ma non diciamo cavolate, grazie



> Che poi e` molto
> poi semplice fare una cosa tipo:
>
> callRemote("sayHello").addCallback(function(str) {alert(str)})
la callback semplifica ? callRemote è una sola funzione ?
devo farne una per ogni tipo di callRemote ??? .... e quando ti passa a te ?



> oppure
>
> function progress(perc) {alert(perc)}
perfetto

pippo.methodName.progress = progress;
che assegni a tutti i metodi che ti pare ... il progress non è una 
chiamata al server eh ... non facciamo confusione, il progress è lo 
stato di ricezione del client della stringa sul server.

Content-Length: 100Kb

il progress restituisce in automatico a readyState 3 la lenght della 
stringa / getHeader("Content.Length"), non fa nulla di asincrono via 
http, sempicemente da un riscontro quando serve.
Per un login un progress non servirà mai ad una fava, per un portale di 
informazioni magari si .... altra cosa che io faccio da tempo e che 
altre lib non hanno (almeno in php e mi sembra nemmeno in .NET, non so 
in Python)




>
> lasciando al server il compito di chiamare perc quando necessario 
> senza scomodare
> il client.
ah certo, tu scomodi il server ...



> charcode non sara` mai piu` di 256 a meno che s non sia unicode 
> perche` per ottenere
> piu` di 256 ti serve un carattere multibyte che non otterrai mai senza 
> usare unicode.
infatti lavora in multibyte ...

>> Ecco cosa tocca fare in JS come in Python (almeno credo sia così, 
>> illuminatemi altrimenti) per ritrovare la len "fasulla" del PHP
> Non c'e` nessuna len fasulla.
credo ti sfugga il significato delle mie parole tra " e " che mi 
evitano, presumendo di avere a che fare non con un robot, di scrivere 
pile di caratteri ... riassumendo in modo semplice



> Assolutamente sbagliato e questo perche` non conosci gli encoding.
bravo


> Ma il problema non lo risolverete ancora :).
lo so bene, lo sanno tutti, il background del php è sempre più incazzato



> Ora pero` sei obbligato a portelo perche` in python questo problema 
> non e`
> nascosto goffamente dal linguaggio ma ti viene sbattuto in faccia 
> facilmente.
bene, quindi il web lavora tutto su u ? devo informarmi a riguardo



> Ma esiste gia` JSON, chissenefrega di una libreria usata in php perhe` 
> in php
> JSON e` lento come la fame?
non condivido



> Esiste gia` JSON, negli altri linguaggi dubito verrai accolto molto 
> differentemente
...
> Se vuoi scrivere la tua libreria in python perche` serve al tuo 
> progetto nessuno
> te lo impedisce ma e` difficile trovarne l'utilita` quando c'e` gia` 
> JSON che
> funziona ed e` _gia`_ implementato in tanti linguaggi e la tua 
> libreria non
> porta vantaggi di alcun genere per questo scopo.
anche la serialize è già scritta per tanti linguaggi ... ma se per 
partito preso devi rinunciare a tutto quello che non è JSON io non posso 
farci niente


> Non mi spiacerebbe ma l'ultima volta che l'ho fatto il risultato e` stato
> disastroso per cui prima mi firmi un documento che ti impedira` di 
> farmi causa
> se la mia reazione sara` vigorosa, poi guardo il tuo sorgente.
ok

> E chi e` il tizio?
quello che se su google scrivi python php serialize è tra i primi col 
suo package che è tra i più noti (l'unico ? io ho visto solo quello ...)


> Si. Pero` a me piace questo modo di comprendere l'open source dove non 
> esiste
> discussione, se io ho un'idea e` giusta per forza perche` e` un'altra 
> idea, non
> c'e` la possibilita` che sia sbagliata o che meriti una discussione in 
> cui
> l'autore si trova a difendere le sue scelte progettuali. Semplicemente va
> accettata e ci si riempie tutti di pacche sulle spalle perche` siamo 
> stati
> bravi a creare l'ennesima variante di una libreria che esiste gia`.
io non voglio alcuna pacca, a me quella versione non andava bene per 
mancanze per me irritanti, riscritta, messo tra i credits, fine, pacce 
di cosa che c'ho già messo un cratere ?
piuttosto parlatemi di come risolvere il cratere, grazie




> Ma tu puoi scriverla come ti pare, te lo sto impedendo in qualche 
> modo? Magari
> ti sfugge che stiamo discutendo di una tua libreria e riguardo alle 
> tue scelte
> di inventare un nuovo formato di serializzazione che non aggiunge nulla a
> JSON
ma non è inventato ... è questo che tutti state dicendo: perchè se c'è 
già JSON .... ma cristoforo, c'era già anche la serialize, da anni per 
tanti lignuaggi quasi quanti quelli per json ...


> (non e` piu` semplice da parsare, non e` piu` veloce in Python se sia
> il tuo che l'altro li si implementa in Pyrex [ma se nessuno ha 
> implementato
> json in C/pyrex/boost/altro significa che non e` un problema per 
> nessuno]).
json in C mi sembra ci sia, json in PHP l'hanno fatto anche in C come 
modulo per evitare che "i server saltassero per aria" ma non è presente 
da nessuna parte, json in python non so quanto sia performante, ma se ha 
i tempi della pear, sviluppate su applicativi che con tanti dati e due o 
tre utenti in più fanno sudare qualunque server ...


> Nasconde semplicemente il procedimento di serializzazione di oggetti 
> arbitrari
> che non va nascosto per varie ragioni che spieghero` solo se avrai voglia
> di discutere invece che prenderla sul personale.
parliamone


> Gli encoding hai ammesso di non conoscerli perche` con php non ti sei 
> mai posto
> il problema... Ora fai l'ironico a riguardo?
e che mi devo mettere a piangere ?