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

[Luca Saiu]

Salute. Rispondo alla seconda parte dell'intervento di Francesco.

nids wrote:
>> [Io avevo scritto:]
> > In the long term new reasonable standards should be written, and
> > compatibility with past protocols and conventions should be
> > discontinued.
>
> Io sono un amante dei tagli netti ma siamo in pochi a pensarla in questa
> maniera: Si veda il caso della programmazione parallela strutturata
> schiacciata a Los Alamos dal peso di $2,000,000,000 (si, miliardi) in
> codice HPF ed MPI che deve continuare a girare e di tool tagliati per
> macchine specifiche

C'e` un'alternativa molto semplice a cui accenno nella nuova versione 
del manifesto: adottiamo dei nuovi standard ragionevoli, 
indipendentemente dalla compatibilita` col passato, e usiamoli.
Parallelamente chi vuole puo` benissimo continuare a usare quelli 
attuali, sulle stesse reti e sulle stesse macchine, anche 
contemporaneamente.
Penso che il caso delle macchine parallele sia leggeremente diverso,
perche` i requisiti della programmazione parallela determinano decisioni
anche sull'*hardware* parallelo. Noi invece vogliamo che le nostre
applicazioni possano girare su hardware convenzionale, quindi non
abbiamo questo problema.

> che fanno l'assunzione che il tipico programmatore e' un fisico o un
> biologo o un matematico o qualcos'altro, ma non un informatico.

Trovare il modo migliore di permettere ai non informatici di
programmare e` un problema affascinante, ma penso che in questa sede
lo possiamo serenamente ignorare.
Chi scrive le applicazioni web oggi se non un informatico e` almeno
un programmatore (altrimenti e` il tipo che si vanta di esserlo; e
in quel caso dovrebbe esserci grato per l'opportunita` che gli diamo
di dimostrare le sue qualita`). Non ci giriamo intorno, i programmi
per web sono programmi, anche se dovrebbero contenere solo la logica
dell'applicazione (la parte facile) e non quella dell'infrastruttura
(la parte difficile, che vogliamo risolvere noi una volta per tutte).

> Io come amante (diciamo fondamentalista :) ) degli oggetti sono convinto
> che anche la programmazione debba essere intuitiva:  Guidata dalla buona
> progettazione delle interfacce degli oggetti offerti dal sistema
> sottostante (per un oggetto 'file' mi apettero' sempre un metodo 'open'
> ed un 'close').
> D'altro canto, so benissimo che un sistema intuitivo richiede, per un
> uso corretto di due cose: 1) esperienza e 2) conoscenza dello strumento
> per un suo uso efficiente.
>
> 1) L'esperienza e' necessaria per conoscere i modi migliori di usare uno
> strumento e usarlo nella maniera appropriata, se per fare un operazione
> ho bisogno di 3 righe di codice non ne devo usare 20. L'esperienza e'
> anche "nell'intorno" quindi sapere soluzioni furbe ed intelligenti in
> altri campi possono essere riusate anche per i propri problemi.
>
> 2) La conoscenza dello strumento (in questo caso i suoi internals)
> permette di riconoscere particolari comportamenti e prevedere
> l'efficienza del sistema.

Ottenere la semplicita` e` difficile. Condivido, e penso che la
validita` questo ragionamento si estenda ben oltre l'uso degli
oggetti.

> Milioni di mosche non potranno mica sbagliarsi!

Pensavo proprio a questa frase ma la volevo lasciare a te :-).

> [...]

> > A web application is made of several "services", i.e. distributed
> > processes exchanging messages.

Ok, un attimo solo. Dopo aver scritto la versione iniziale del manifesto
ho cambiato idea su questo punto; mi sembra d'aver accennato il nuovo
modello a Michele, e forse anche ad Andrea. Il punto e` questo:
non e` necessario mappare un servizio in un processo; e` conveniente
che prevediamo piu` casi:
Un servizio potrebbe essere implementato come:

1) un intero processo, magari diviso in piu` thread: questo era l'unico
caso possibile nel modello precedente.
2) parte dello stato globale di un processo. I thread possono invocare
direttamente le procedure in modo sincrono, senza usare nemmeno
commutazione di thread e semafori (che pero` spesso sono necessari per
altre ragioni)
3) uno o piu` thread di un processo che, preso tutto insieme, implementa
anche parti di altri servizi.
4) alcuni thread che appartengono a piu` processi distinti che presi 
tutti insieme implementano il servizio, e magari parti di altri servizi.

Questa organizzazione piu` complessa ci porta un vantaggio importante:
permette di condividere dati in modo molto efficiente tra servizi
distinti.

La API per lo scambio di messaggi tra servizi, cioe` il meccanismo RPC,
*non* cambia rispetto a quanto gia` proposto; l'unica cosa che puo` 
cambiare e` l'inizializzazione, cioe` l'apertura della porta. Detto 
diversamente, usare la memoria condivisa da due thread dello stesso
processo e` semplicemente un altro *protocollo* che si puo` usare per
scambiarsi messaggi, esattamente come si puo` fare adesso con TCP, e
come si potra` fare in futuro con SSL e HTTP.
E` un protocollo estremamente efficiente, ancora di piu` dei socket in
locale. Usandolo possiamo implementare anche servizi molto
"lightweight", quindi con funzionalita` semplici e ben definite, senza
aver paura di perdere troppa efficienza per questo.

Le decisioni sull'allocazione dei servizi su processi e thread
dovrebbero essere ritardate il piu` possibile, idealmente fino al tempo
di inizializzazione, e quando serve anche di esecuzione. E` un vincolo
inutile e gravemente limitante dover stabilire addirittura a tempo di
*progettazione* che un certo servizio giri su una certa macchina.

Nel nuovo modello allocare i servizi sui processi e sui thread diventa
un ulteriore problema da risolvere (nessuno di noi pensa di farlo fare
al programmatore, vero?), ma e` un problema interessante e risolverlo
bene ci permetterebbe di fare cose divertentissime: discovery, 
adattivita`, fault tolerance, migrazione, worker generici che offrono 
tempo di processore a servizi qualsiasi, servizi molto dinamici che 
appaiono e scompaiono sulla rete.

Qualcuno di voi e` interessato alla programmazione parallela? Io si` :-).

Chi fa programmazione web oggi e parla di bilanciamento del carico,
per esempio, propone delle cose che farebbero venire un attacco
isterico a Vanneschi (cose come "mettiamo il database degli utenti
qui e quello dei documenti su quest'altra macchina, cosi` poi
scala"). Proteggiamo la sua salute. Facciamo le cose bene.

> > In nearly all cases the simplest style of
> > communication
> > is required: synchronous messages. An RPC interface should be used,
> > possibly
> > augmented with some form of asynchronous RPC, for non-functional
> > interfaces.
>
> Se ho capito bene la tua proposta e' quella di creare dei sistemi di
> programmazione distribuita in grado di scambiarsi messaggi in maniera
> semplice ed intuitiva.

Si`, ed anche efficiente. E soprattutto aspetto fondamentale,
indipendente dal protocollo: la sintassi per una RPC e` sempre la
stessa, indipendentemente dal fatto che il messaggio viaggi sopra
TCP, SSL, HTTP, o che la variabile venga passata copiando un puntatore.

> Il sistema RPC da te proposto, cito la mail con il Golfarini: ((rpc port
> f) parametro-1 ... parametro-n), e' molto semplice (dal punto di vista
> dell'uso) ma ho delle puntualizzazioni:
>
> - Per un sistema server<->server e' l'ideale, in quanto tutti i servizi
> sono acceduti in maniera omogenea. Una cosa buona sarebbe quella di dare
> una generica idea di "funzione" la cui invocazione viene passata al
> run-time (e a chi altri?) e quest'ultimo decide se fare una RPC o una
> LPC. Io devo poter ignorare il fatto che la funzione sia remota o
> locale.

Certo, e infatti puoi ignorarlo. Secondo il nuovo modello proposto sopra 
puoi anche avere delle chiamate 'apparentemente remote', che di fatto 
sono locali anche se usano l'interfaccia RPC. La decisione in un
qualche senso e` presa dal runtime, ma non credo che tu intenda quello
che intendo io: in realta` *in fase di creazione della porta* verso il
servizio (eventualmente) remoto si creano le strutture dati che poi
verranno usate per i messaggi. La decisione non viene certo presa
per ogni chiamata.

Una complicazione in questo passaggio e` data dal mio desiderio,
immagino condiviso anche da voi, di avere fault tolerance a livello di 
connessioni. Devo ancora pensare al modo giusto di risolvere questo, ma
mi piacerebbe una soluzione che nascondesse i fault a questo livello
quando possibile.
Notate che questo *non* e` il caso delle eccezioni scatenate su un
servizio remoto, di cui discutevo l'implementazione con Matteo. Qui
si parla di errori *di rete*.

> Pero' ci serve un modo semplice ed intuitivo per
> specificare/trovare le funzioni discriminando fra quelle locali e quelle
> che non lo sono. Volendo un run-time distribuito fra i server sarebbe
> l'ideale.

Gia` nell'implementazione corrente c'e` un minimo di reflection: le
procedure esportate list-exported-procedures e
describe-exported-procedures (vedi rpc.scm). Questo non ci basta, e`
limitato a un solo servizio verso il quale sia ha gia` una porta, ed
e` un meaccanismo che ho pensato soprattutto per l'uso interattivo.
Ci serve un vero sistema di discovery. Questo va progettato e
implementato. Puo` essere un pezzo di libreria nascosta in rpc.scm?
Un servizio? Piu` servizi? Un servizio distribuito? A proposito, come
funzionano i servizi distribuiti?

Forse senza rendercene del tutto conto stiamo parlando di un sistema
operativo distribuito (ma non mi sembra che il concetto sia ben definito
o sufficientemente distinto dall'idea di runtime distribuito). Secondo
me quello che stiamo proponendo *e`* un runtime distribuito. No?

> [Francesco fa notare, giustamente, che la compatibiltia` coi browser
> esistenti e` importante e che un'interfaccia utente che giri su un
> browser non si integra facilmente come parte del nostro sistema.
> Francesco propone di generare HTML e XML dinamicamente come in Ajax,
> ma in modo che l'utente finale non li debba vedere].

Condivido quasi tutto. Ho un'idea piuttosto convincente a proposito di
questo, ma e` impegnativa da implementare nell'infrastruttura. Richiede
un messaggio a parte. Due soli punti: no, XML no. Si puo` fare molto
meglio. E perche` non generare automaticamente anche JavaScript?

> - Il sistema di memorizzazione ortogonale mi piace molto in quanto
> permette di evitare l'uso di dati strutturati come i tradizionali DB.

Ma non e` uno scherzo da implementare, nonostante Scheme in parte si
presti. Stavo quasi pensando di rinunciare a questo punto e scrivervelo
in un messaggio, poi mi e` venuto in mente di provare a usare le
continuazioni. Non ho ancora implementato niente tranne qualche prova,
ma mi sono convinto che siano lo strumento giusto. Penso che servira`
anche un po' di codice C.

Le continuazioni sono sicuramente l'aspetto piu` difficile di Scheme,
e per questo il piu` contestato, ma permettono di fare delle cose
molto belle, particolarmente se usate insieme alle macro. I
principianti possono rimanere molto impressionati, leggete queste
cose con calma.

Un'introduzione molto informale:
http://www.madore.org/~david/computers/callcc.html

Un'altra introduzione: particolarmente utili i link:
http://en.wikipedia.org/wiki/Continuation

Ripeto, e` roba difficile. Ma ci si possono fare giochetti come questi:
http://gd.tuwien.ac.at/languages/scheme/tutorial-dsitaram/t-y-scheme-Z-H-15.html
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg00560.html

> Una opportunita' interessante e' quella di avere un sistema di
> "ibernazione" distribuito: lo stato dei vari pezzi del sistema e'
> salvato  e/o puo' essere salvato in modo che l'applicazione diventi in
> un certo senso un input per una sua futura esecuzione.

Si`, a livello astratto e` questo. Ma in presenza di fault (ed e` quello 
il caso interessante) non e` facile determinare cosa succede nel 
boundary tra un host e un altro. Bisognera` pensarci bene. Salvare una 
snapshot dello stato di un processo e` (facciamo finta) facile. Ma il
problema e` come ripristinare l'interazione con gli altri processi e 
servizi che possono aver salvato lo stato in un momento diverso, o che
possono averlo cambiato...
C'e` da pensarci. Tutte cose bellissime.

Buona serata.


--
L.