WEBVTT

00:00:04.095 --> 00:00:06.573
[Musica]
(Bricovideo)

00:00:06.573 --> 00:00:09.876
(Piccolo esperimento di Andreas Formiconi)

00:00:09.876 --> 00:00:14.640
(Tutti i diritti ceduti)

00:00:14.640 --> 00:00:18.620
(Fine della II Parte)


00:00:18.620 --> 00:00:23.484
(Abbiamo rivisto: 
Il meccanismo PHP-HTML -> Bowser
HTML -> CSS...
... + JS)

00:00:23.484 --> 00:00:25.761
(...+AJAX)

00:00:25.761 --> 00:00:29.438
(-> Il passaggio progressivo del carico di lavoro dal server al client -> Ottimizzazione...)

NOTE Paragraph

00:00:29.438 --> 00:00:31.947
(HTML PHP MySQL SERVER
BROWSER CLIENT)
[Andreas Formiconi] Ecco,fino ad ora,

00:00:31.947 --> 00:00:38.522
(BROWSER-CLIENT ripetuti + volte)
ci siamo sulla relazione tra due entità, sostanzialmente: il client e il server.

00:00:38.522 --> 00:00:42.349
Ora allontaniamoci, allarghiamo la visione.

00:00:42.349 --> 00:00:47.162
Allarghiamo la visione e vediamo le cose più da lontano.

00:00:47.162 --> 00:00:52.996
Evidentemente, un server serve tanti client

00:00:52.996 --> 00:00:59.369
e quindi noi dobbiamo immaginare una miriade di client

00:00:59.369 --> 00:01:04.137
che sono tutti potenzialmente collegati

00:01:04.137 --> 00:01:10.527
E ora immaginiamo che molti di questi client facciano delle richieste al nostro server

00:01:10.527 --> 00:01:17.252
E immaginiamo che il meccanismo sia quello basato su PHP HTML

00:01:17.252 --> 00:01:24.416
ogni richiesta si risolve in un lavoro che il server deve fare per quel client

00:01:24.416 --> 00:01:33.754
é evidente che se il carico aumenta oltre un certo livello il server può rischiare di andare in crisi

00:01:33.754 --> 00:01:39.821
di non farcela o di rallentarsi per poter rispondere a tutte queste richieste

00:01:39.821 --> 00:01:45.172
e questo può porre dei limiti... alle dimensioni della comunità dei client

00:01:45.172 --> 00:01:51.248
che si può pensare di soddisfare con un server

00:01:51.248 --> 00:02:00.268
Immaginiamo ora invece di poter fare delle richieste al server che confidano sostanzialmente

00:02:00.268 --> 00:02:03.585
nell'esecuzione di codice java scrip

00:02:03.585 --> 00:02:11.116
Questo significa che una gran parte di lavoro viene svolto da ciascun client

00:02:11.116 --> 00:02:18.792
Ogni client fa esattamente la quantità di lavoro che serve a lui stesso

00:02:18.792 --> 00:02:25.735
Quindi alleggerendo potenzialmente, in maniera massiccia il carico di lavoro del server.

00:02:25.735 --> 00:02:32.125
Ecco questo processo è un po' quello che si è verificato in generale

00:02:32.125 --> 00:02:38.721
ecco noi abbiamo un esempio perchè Java script non è l'unico modo per far lavorare il client

00:02:38.721 --> 00:02:45.663
Il server può lavorare anche in altri modi, ma sono pezzi e componenti esemplificativi

00:02:45.663 --> 00:02:49.830
e sono diciamo quelli più importanti, più significativi

00:02:49.830 --> 00:02:56.397
Ma la cosa rilevante è rendersi conto che il codice

00:02:56.397 --> 00:03:04.792
diciamo si è fluidificato e si è distribuito in una maniera sempre più ottimale

00:03:04.792 --> 00:03:11.235
fra questi innumerevoli nodi che compongono

00:03:11.235 --> 00:03:15.972
alla fine la rete, nodi fatti di tantissimi

00:03:15.972 --> 00:03:20.131
client e anche di tantissimi server

00:03:20.131 --> 00:03:24.568
La possibilità che ciascuno dei nodi svolga

00:03:24.568 --> 00:03:30.294
una elevata quantità di lavoro ha reso possibile

00:03:30.294 --> 00:03:33.638
la nascita di nuovi fenomeni e alla fin fine

00:03:33.638 --> 00:03:37.025
tutto sommato il fenomeno più ampio che contiene

00:03:37.025 --> 00:03:40.649
tutti questi, che è quello identificato con la NUVOLA

00:03:40.649 --> 00:03:43.126
THE CLOUD

00:03:43.126 --> 00:03:46.348
C'è un elemento fra quelli che abbiamo visto

00:03:46.348 --> 00:03:49.938
con appena un po' di attenzione in più

00:03:49.938 --> 00:03:53.209
che non è comparso finora in questo piccolo discorso

00:03:53.209 --> 00:03:56.335
ed è l'XML

00:03:56.335 --> 00:03:58.693
che abbiamo capito essere importante

00:03:58.693 --> 00:04:01.857
perchè è il modo più generale e pervasivo

00:04:01.857 --> 00:04:04.110
con il quale oggi si distribuiscono

00:04:04.110 --> 00:04:08.641
e si diffondono sostanzialmente i contenuti

00:04:08.641 --> 00:04:10.206
a prescindere da come essi poi

00:04:10.206 --> 00:04:13.154
verranno rappresentati, ordinati,eccetera

00:04:13.154 --> 00:04:17.921
ebbene dov'è l'XML in questo schema?

00:04:17.921 --> 00:04:26.241
Ecco l'XML in realtà sta in quella miriade

00:04:26.241 --> 00:04:31.141
di blocchi di informazioni che viaggiano

00:04:31.141 --> 00:04:33.225
fra un nodo e l'altro.

00:04:33.225 --> 00:04:37.607
Abbiamo visto i feed che sono in realtà dei

00:04:37.607 --> 00:04:40.653
frammenti di codice XML

00:04:40.653 --> 00:04:44.854
Abbiamo visto l'OPML, è una sorta, una sottospecie

00:04:44.854 --> 00:04:49.150
di XML; abbiamo visto che se vogliamo estrarre

00:04:49.150 --> 00:04:51.556
le informazioni da un blog e trasferirle in un altro

00:04:51.556 --> 00:04:54.832
anche questo passa attraverso l'XML

00:04:54.832 --> 00:04:59.799
e così via. Ecco l'XML è il collante

00:04:59.799 --> 00:05:03.104
che in qualche maniera collega, che fa transitare

00:05:03.104 --> 00:05:07.514
i contenuti di tante nature diverse fra i diversi nodi

00:05:07.514 --> 00:05:09.586
per realizzare quella che ormai conosciamo

00:05:09.586 --> 00:05:12.843
come la nuvola appunto, the cloud

00:05:12.843 --> 00:05:17.070
e della quale poi in qualche altro post vedremo alcune ...