DI JOHN MADERO

L’avreste detto che il leader mondiale nelle web application avrebbe lanciato un’estensione per browser dedicata alle applicazioni offline??
Sembrerà anche paradossale, ma quella che a una prima analisi può apparire come un’entrata in un nuovo mercato (quello delle applicazioni offline), è in realtà una mossa vincente di primaria importanza con un valore di “complementarità” nei confronti del lavoro già svolto: una mossa che, come alcuni hanno già detto, trasformerà, con l’implementazione di Gears in tutti i software Google, l’intero panorama dei web services di BigG.
Se siete dei programmatori web, e magari avete anche avuto a che fare con AJAX, sapete bene che alcuni dei principali problemi sono il riconoscimento dello stesso utente in due sessioni diverse (i sistemi per memorizzare i dati sul client, cookies in primis, sono spesso poco efficaci), la gestione dell’interfaccia utente mentre il vostro codice javascript sta elaborando in locale o contattando il web server, e infine l’improponibile dipendenza dalla cache del browser per visualizzare una pagina offline.
Ed ecco quindi nascere Google Gears (completamente opensource), presentato da Eric Schmidt in persona al Google Developer Day di Sydney lo scorso 31 maggio.

Immagine del post

Google Gears non è un framework, ma piuttosto un’estensione applicativa del browser che funziona da “server” per le vostre pagina con codice javascript, in modo da supplire alle funzioni del regolare server remoto quando la connessione non è disponibile.

Google Gears si divide in tre Moduli / API:

Immagine del post LocalServer
E’ il modulo di Google Gears che permette la visualizzazione della pagina e l’esecuzione di codice javascript anche se il computer è sconnesso dalla rete.
Come funziona?
Semplicemente, attraverso questo modulo, possiamo memorizzare in una sorta di “master-cache” di Google Gears vari tipi di file (i più comuni saranno .html, .js e altri formati statici come .png, .pdf).
Quando il computer è sconnesso, al momento della richiesta HTTP, LocalServer subentrerà e, se presente, restituirà il file dopo averlo prelevato dalla cache di Google Gears (da non confondersi con quella del browser).
Se aggiorniamo la pagina dopo aver resettato la cache, riceveremo la solita 404.
Immagine del post Database
Il modulo Database non solo ci dà la possibilità di salvare dati sul pc client, come fa un cookie, ma ci offre un sistema di database relazionale completo!
Insomma, con Database possiamo eseguire normalissime query SQL dal nostro codice Javascript; il sistema di database utilizzato è SQLite, un leggerissimo e versatile dbms scritto in C, tra l’altro integrato in Php 5.
I dati verranno memorizzati, come è prassi per SQLite, in un unico file sul vostro computer.
Immagine del post WorkerPool
Quando usiamo AJAX e lanciamo richieste sincrone al server, fino al momento in cui il nostro client non riceve risposta la nostra interfaccia grafica rimane bloccata.
In realtà però accade la stessa cosa se eseguiamo del codice in locale che richiede molti calcoli: fino a che il processo non sarà completato la nostra interfaccia rimarrà bloccata.
WorkerPool risolve questo problema perchè permette di eseguire del codice javascript in background senza bloccare l’interazione dell’utente con la pagina.

A questo indirizzo trovate vari esempi di utilizzo di Google Gears (si tratta pressochè di uno script di esempio per ogni modulo descritto sopra).

E tu, programmatore web o semplice utente, cosa ne pensi di Google Gears?

Riferimenti: questo , questo e questo

RISPOSTA DI NECOSI

In principio le applicazioni erano offline. In seguito si è sviluppato il web ed abbiamo assistito al boom della new-economy. Il web ha avuto una sua evoluzione, indipendente dalla applicazioni offline, ed è andato nel tempo costituendo una branchia dell’informatica a parte.

Oggi sono sempre piu’ frequenti le Web Application. Il culmine si è avuto quando si è iniziato a parlare di “sistemi operativi” on line. E’ stato montato un intero palcoscenico dedicato al web e anche per questo motivo spesso si commettere il grave errore di confondere il web con internet.

Il web è nato per visualizzare documenti, ipertestuali e leggeri. Il web non è altro che un protocollo. Prima di questo periodo caotico, per ogni servizio esisteva un protocollo, ma oggi stiamo assistendo ad un fenomeno pericolosissimo, l’abbattimento del concetto del protocollo.

Ad esempio, in un primo momento la posta elettronica usava protocolli ben definiti. Gli utenti la visualizzavano, potevano scegliere se conservarla sui server o scaricarla sul proprio computer per un’ipotetica visualizzazione offline. Tutto questo era possibile con un semplicissimo client di posta elettronica. C’erano i protocolli che definivano tutto questo, e si viveva felici.

Poi per motivi economici i grandi fornitori di servizi di posta elettronica hanno deciso di basare i loro sistemi su servizi di Web Mail. Questo è stato l’inizio della fine. Molte aziende hanno limitato l’accesso al servizio di posta forzando il passaggio per il web. Si è iniziata a creare cosi’ una gran confusione. Alcuni tool “hackeravano” queste limitazioni, ma non era semplice per tutti usare questo genere di soluzioni.

Questa confusione tra web ed internet ha portato gli sviluppatori a lavorare su progetti sbagliati alla base. Andrebbero sviluppato protocolli, i quali andrebbero standardizzati. Poi ci si potrebbe sbizzarrire con lo sviluppo di client, ma nulla di più. E’ in serio pericolo l’interoperabilità. E’ un problema che è sempre esistito, ma gli iteeressi economici hanno sempre minato questo concetto, facendolo sgretolare pian piano negli anni.

Un esempio eclatante sono le Chat (IRC), che sono morte per far spazio ai servizi di IM (msn), che usano protocolli proprietari per fare cio’ che prima era gia’ possibile fare liberamente. Ma chi ha il capitale, ha anche il potere, e decide per le masse che ignare seguono la “moda” del momento. Per quando possa sembrare astratto questo discorso, non lo è affatto.

Personalmente il mio calendario, i miei appuntamenti, i miei documenti, le mie email, I MIEI BIT, li conservo sulla mia macchina, e non li lascio di certo gestire a qualcun altro. La mania della delegazione ci fa perdere ogni giorno il controllo della nostra vita.

Oggi qundi, i ragazzi di Google, stanno lavorando ad una soluzione per riportare Offline le applicazioni Online, ma piu’ che Online qui si parla solo di web, e la differenza è sostanziale perchè online significa in internet e non nel web!

Portare Offline le Web Application non è una soluzione, ma semplicemente un modo per raggirare il problema.
E’ immediato capire che il problema rimane. Esiste una sola soluzione, e non è di certo rappresentata da Google Gears. Possiamo solo fare inversione di marcia, riappropriandoci degli strumenti giusti ed usare quelli, diffidando ogni giorno dagli specchietti per le allodole continuamente offerti dalla grande azienda del momento.___

La lezione di Oilproject che ti suggeriamo oggi è Architettura Bizantina: l’Ippodromo di Costantinopoli.