Re: Come usare Scheme sul client [Was: Re: [Wpaisb-devel] MANIFESTO il mio diritto di argomentare sul MANIFESTO in maiera convulsa e 'circoncisa']

[Luca Saiu]

Ciao Francesco.

nids wrote:
> 0) Della novita' del progetto: Il progetto, per se', non e' una novita'
> sconvolgente.

Assolutamente vero. La situazione pietosa in cui versa la programmazione 
web mi irrita cosi` tanto proprio perche` fare meglio di cosi` non 
richiederebbe un grande sforzo: sarebbero tutte idee gia` note. Ma 
naturalmente noi, visto che siamo qui, miriamo a fare anche qualcosa in 
piu` rispetto al solo correggere i difetti che vediamo. Alcune idee per 
quanto note sono molto poco usate in pratica, per es. la persistenza 
ortogonale, o anche un'applicazione ragionevole (automatica) della fault 
tolerance. E avere la stessa interfaccia (semplice ed espressiva, non 
SOAP) implementata trasparentemente su diversi protocolli? Chi lo fa adesso?

Direi di non sottovalutare l'innovativita` del progetto. Alcune delle 
cose che vogliamo fare non sono difficili (altre si`), ma nonostante 
questo non esiste niente di paragonabile in giro.

> Di sistemi client/server ce ne sono parecchi in giro e per
> tutti i gusti.

Non credo che il nostro modello si possa definire client/server; certo, 
in ciascuna connessione esistono un client e un server, ma queste sono 
solo definizioni che servono a noi per distinguere chi invia un 
messaggio da chi lo riceve; una volta che un servizio/processo/thread e` 
avviato e attende richieste diventa una risorsa come tutte le altre. E 
chi lo invoca, anche se per lui fa da client, e` un server a sua volta. 
Non sono sicuro che si possano definire tecnicamente peer (gli esperti 
di rete qui siete tu e Michele), ma di certo una volta avviati hanno un 
ruolo simmetrico tra loro.

> Cio' che ci interessa e' (di)mostrare e' che pescando i
> pezzi dalla stessa cesta da cui gli altri hanno pescato, possiamo
> comunque montarli in maniera corretta e fare qualcosa che sia piu'
> informatico che ingegneristico.

Mmm. Si`. Ma noi peschiamo anche da qualche altra cesta che per limiti 
culturali chi ha costruito l'infrastruttura del web non ha voluto 
toccare; l'uso avanzato dei linguaggi, prima di tutto.

Prima di parlare della parte importante non posso trattenermi dal
rispondere a questo, per stupire i non iniziati:

> Dobbiamo scrivere un interprete scheme in javascript per tutti i casi di
> metaprogrammazione? Se i casi di metaprogrammazione diventassero troppo
> pesanti sarebbero da sconsigliare?

Un sistema Lisp, anche compilato, contiene *sempre* anche un interprete
nel runtime (eval e primitive-eval), che sia usa in alcuni casi di
metaprogrammazione; negli altri casi si usano le macro. In genere il
codice valutato a runtime con eval non e` molto, e non da` problemi
di prestazioni. Le macro vengono espanse una volta al loro primo
utilizzo, quindi sono praticamente gratis.
Volendo implementare b) scriverei eval e primitive-eval in Scheme, e
le compilerei nel linguaggio target (JavaScript) come qualsiasi altra
funzione Scheme. Finirebbero poi nella libreria del runtime (in
JavaScript).


Ok, passo a commentare le ipotesi d'implementazione.

> 1) Della struttura client: Come ho gia' detto abbiamo due opportunita'
> ed entrambe interessanti:

Sono quasi esattamente le stesse che pensavo di proporre anch'io. La 
Right Thing esiste e, soprattutto, e` unica :-).

>         a) Client *non* browser: In questo caso quando il client parte
> e' solo un canvas vuoto che ti chiede "dove saresti voluto andare
> ieri?" (oggi e domani sono gia' occupati :) ) tu gli dai l'indirizzo
> pinco.palla del server, l'applicazione si scarica i pezzi e parte.

Ok. Nel caso a) il client e` un semplice worker che esegue del codice 
che viene dall'esterno. Questa e` una funzionalita` importante anche per 
l'avvio di servizi su server: sono tutti i casi in cui una risorsa di 
calcolo (chiamiamola "worker") viene creata e comunica agli altri: 
"esisto, datemi qualcosa da fare".

Un requisito non essenziale ma desiderabile: vorrei che un servizio 
potesse essere avviato in modo sia "attivo" (l'utente umano avvia 
manualmente un servizio, in questo caso sul client: l'interfaccia utente 
e` un servizio) che "passivo" (un worker esistente riceve il codice di 
un servizio da eseguire), senza cambiare il codice. A prima vista mi 
sembra piuttosto facile.

Ci sono evidenti problemi di sicurezza da risolvere. Si possono evitare 
in alcuni casi in cui si esegue codice trusted (forse in tutti i casi di 
avvio attivo), o dopo un'autenticazione avvenuta con successo. In alcuni 
casi il problema *non* si puo` evitare, e serve una qualche forma di 
sandboxing.

> Una domanda potrebbe essere: Come si scaricano i pezzi? Tutti insieme o
> un pezzo alla volta?
> Con un (possible) call-tree, ottenutenuto in maniera  statica durante la
> compilazione, possiamo tirare giu' l'albero "twig-by-twig".

Non ho opinioni molto forti su questo.

> Ovviamente tutto cio' che e' metaprogrammazione ce la battiamo alle 
> pudenda :)

La metaprogrammazione fatta bene e` divertente.

> E' necessario comunque, per motivi "storici," usare la porta 80 e qualcosa
> simil-HTTP(S) per via di firewall, filtri ed altre amenita'.

Vorra` dire che ci implementeremo il protocollo HTTP, e magari HTTPS. 
Questo e` l'*unico* motivo ragionevole per implementarli. Vanno usati, 
comunque, solo quando necessario: non credo che sia sempre l'unica 
possibilita` nemmeno sul client.

>         b) Client browser: In questo caso si potrebbe compilare la parte client
> dell'applicazione da scheme a javascript(con ajax).

Si`, ed e` la parte che in un messaggio precedente definivo impegnativa 
da realizzare; per quanto Scheme sia un linguaggio semplice farsi un 
compilatore da Scheme a JavaScript non e` completamente banale. In piu` 
noi non vogliamo solo R5RS (e presto R6RS), ma un wrapping il piu` 
completo possibile della libc, e in piu` anche dell'altro, se possibile. 
Guile e` molto buono da questo punto di vista, anche se piuttosto lento; 
inoltre ho simpatia per chi ci lavora :-).

Usare due implementazioni di Scheme diverse una sul server e l'altra sul 
client non mi sembra realistico: non potremmo pretendere compatibilita` 
piena; sarebbe desiderabile che i servizi senza GUI potessero girare 
indifferentemente su server o su client.

Non guadagneremmo granche` a passare a un'altra implementazione di 
Scheme, a meno che non supporti gia` JavaScript come linguaggio target. 
Una soluzione che spero che nessuno di noi consideri seriamente sarebbe 
quella di usare Scheme compilato in JavaScript anche sul server, per 
compatibilita`.

Si puo` anche pensare di scrivere solo un interprete Scheme scritto in 
JavaScript. Immagino che girerebbe molto lento e non migliorerebbe di 
molto la situazione, visto che le librerie restano comunque la parte 
piu` difficile e lunga da implementare; e la loro difficolta` di 
implementazione non dipende dal fatto che si usi un interprete o un 
compilatore. Francesco accenna anche all'idea di un compilatore 
incrementale, una sorta di turpe e incestuoso JIT che genera codice 
JavaScript a runtime, da passare a un interprete. Non vedo vantaggi in 
questa soluzione, ma e` divertente considerare l'idea.

L'alternativa piu` credibile sarebbe avere un compilatore Scheme, 
scritto o retargeted da noi, che generi codice per due backend diversi:
- JavaScript
- C oppure assembler per tutte le piattaforme ragionevoli, oppure la mia eAM


Tutto questo e` decisamente impegnativo da realizzare; in tutta 
sincerita` non credo che abbiamo la motivazione sufficiente per farlo.


Propongo una terza alternativa di compromesso al posto di b):

c) un plugin nativo e portabile per Mozilla (se qualcuno vuole lo puo` 
portare anche su quell'altro browser) che si attacchi a Guile e permetta 
di eseguire codice Scheme su client, usando le finestre del browser.

Vantaggi: - uso di un solo sistema Scheme per client e server
          - presumibilmente potremmo evitare i limiti di una GUI basata
            su HTML
          - Puo` darsi che potremmo evitare HTML del tutto, e magari
            attaccarci direttamente a Gtk+ o Qt
Svantaggi: - l'utente finale dovrebbe installare un plugin, per quanto
             libero e gratuito
           - portabilita` ridotta: solo i browser recenti sarebbero
             supportati (ma non credo che dovremmo preoccuparci)

Penso che implementare c) sia completamente realistico, anche se sul 
lato client partirei comunque da a).

La seconda parte domani :-)

> 2) Realizzazione di interfacce: Un grosso "vantaggio" delle web
> applications di oggi e' che le interfacce grafiche sono facili da
> programmare e si possono fare "carine" con poco (interprete-HTML
> permettendo). Poi con sistemi quali JSF e' possibile staccare la parte
> grafica dalla logica dell'applicazione. Possiamo fare un sistema che
> renda semplice creare anche le interfacce? Non vorrei che si finisca in
> un sistema alla X (vedi Xt etc...).
>
> 3) Della struttura del/dei server: I server comunicano tra loro
> esattamente come nell'interazione client-server: RPC. Dato che
> l'interazione e' la stessa: Un client si attacca ad un solo server? Un
> client puo' direttamente attaccarsi a piu' server? Come conosco le varie
> risorse? Queste infomrazioni vengono date al client dal primo server al
> quale si collega, o le deve gia' sapere da prima?
>
> 4) I nostri concorrenti diretti: I nostri "concorrenti" diretti, sono i
> web services. Se noi vogliamo fare esattamente lo stesso senza XML,
> aggiungiamo poco, sarebbe bello riuscire a fare di piu' e meglio. Fare
> meglio ci vuol poco, fare di piu' e' impegnativo. Cosa possiamo fare
> piu' di loro, dato che fare meglio e' facile?
>
> Per ora penso possa essere tutto, se mi viene in mente qualcos'altro vi
> faro' sapere :)
>
> Ciao a tutti: In Italia sono le 19:44 quindi buona cena!
> Francesco