[Python] mod_python ed il giusto handler

[Lawrence Oluyede]

> 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)

Mi scrivi 5 righe della parte Python di gestione della roba JS con la
tua libreria?

> approccio a specchio, puoi gestie oggetti client e server allo stesso
> modo sul client come sul server

Non trovo un motivo valido per avere questa caratteristica
sinceramente, magari mi sbaglio

> > 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 ...

E' troppo perchè sono varie funzioni.

> 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

Quindi scrivi una lib in Python per risolvere un problema che ha solo
quella schifezza di PHP?

> scrivi una classe (funzione) fine, non devi poi rifare niente, ti
> ritrovi l'istanza malipolabile, inviabile, etc etc

fammi vedere un esempio :-)

> 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.

Interazione avanzate in AJAX?

> > 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 ?

Che vuol dire tipo di callRemote? La callRemot chiama una funzione e
piglia il valore di ritorno. Che c'è da riscrivere?

> bene, quindi il web lavora tutto su u ? devo informarmi a riguardo

Tutto su che?

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

L'hai detto tu che non usi JSON perchè non c'è una libreria in PHP
decente preinstallata. Tra l'altro non avrai lo stesso problema di
deployment con la tua libreria rispetto a quelle più performanti per
PHP ma non preinstallate?

> 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 è un partito preso, è un non reinventare la ruota

> 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 ...

E quindi?

> 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 ...

La tua lib in pyrex sarà ancora meno portabile sui server che non
preinstallano le librerie JSON in PHP performanti, vero?

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