Una volta definito il concetto di provider, il modo in cui interagisce col sistema operativo (e in generale come viene utilizzato il canale di comunicazione fra i due), rimane da analizzare in che modo operano le applicazioni e il ruolo che rivestono rispetto agli altri due attori.
In un ecosistema cloud-aware come quello esposto finora qualunque applicazione può trarre immediatamente beneficio delle funzionalità cloud senza alcun bisogno di apposito codice, perché la gestione delle risorse è totalmente trasparente a esse, le quali in teoria possono benissimo girare senza curarsene.
Infatti è l’utente, e soltanto lui, a decidere quali file e/o cartelle devono essere sincronizzati col provider o i provider che sono stati registrati nel sistema. Quindi se una certa applicazione facesse uso delle cartelle X e Y e dei file A, B, e C, e l’utente volesse sincronizzare X, B e C, sarebbe sufficiente accedere alle proprietà di questi tre oggetti e selezionare i provider a cui dovranno essere associati.
Lo stesso concetto è applicabile al registro di sistema (registry) per i s.o. che prevedono un meccanismo di questo tipo, dove alle cartelle e ai file si sostituiscono i rami e le foglie/nodi dell’apposito albero di cui si vuole eseguire la sincronizzazione col cloud.
Una soluzione di questo tipo, seppur applicabile anche a qualunque applicazione esistente da ben prima che esplodesse il fenomeno, si porta dietro almeno un paio di problematiche non di poco conto che possono anche compromettere l’esperienza finale dell’utente.
La prima riguarda la scelta delle risorse da sincronizzare, tutt’altro che banale poiché implica la conoscenza del funzionamento del programma. Se con software del calibro di Word risulta abbastanza semplice (è l’utente che decide dove memorizzare i suoi documenti, potendo anche rivolgersi a una cartella “cloud”), con Opera e il suo servizio Opera Link diventa molto difficoltoso (serve rintracciare i file in cui memorizza bookmark, visite, e altro).
Peggio ancora con la configurazione dell’applicazione: recuperare i relativi file richiede un impegno non indifferente, ma se lavoriamo in un ambiente Windows e si fa uso del famigerato registry, ecco che l’impresa può risultare decisamente faticosa, arrivando a poter richiedere l’impiego di applicazioni ad hoc per il monitoraggio delle risorse modificate.
Poi si presenta il classico problema della diversità di s.o. e/o piattaforma hardware su cui girare, che può richiedere file posizionati in parti diverse del filesystem o chiavi del registry in apposite diramazioni, fino a configurazioni ad hoc per lo specifico s.o. e/o hardware.
A conti fatti si può provvedere a impostare tutto manualmente sulle varie macchine che utilizziamo, con le accortezze nel caso per far funzionare ogni applicazione correttamente, e potendo gestire anche le configurazioni ad hoc memorizzandole in opportune locazioni del/i cloud, ma oggettivamente l’esperienza è tutt’altro che esaltante, e potrebbe essere così onerosa per l’utente da farlo desistere dall’utilizzare questi servizi.
E’ molto meglio, quindi, passare al concetto di applicazione cloud-aware, dove è la stessa che provvede, alla partenza, a registrare le risorse di cui fa o farà uso, inclusi file di configurazione ed eventualmente il registry, tramite apposite API che il s.o. mette a disposizione, con la possibilità di una contestuale registrazione di un provider da utilizzare (se non fosse già presente).
Passando tutto dal s.o. al solito il controllo sarebbe assoluto e rimarrebbe nelle mani dell’utente perché, ad esempio, i tentativi di registrazione del nuovo provider comporterebbero la visualizzazione di un apposito dialogo con le informazioni sulla richiesta e l’inserimento della password di amministratore per acconsentire all’espletamento dell’operazione.
Si tratta di uno scenario di gran lunga più semplice e amichevole, al prezzo di un disturbo minimo (alla sola prima esecuzione su ogni macchina utilizzata).
Rimane il problema della memorizzazione della configurazione per i diversi s.o. e/o piattaforme hardware. Bisogna innanzitutto separare le informazioni, fra quelle che sono “agnostiche” (ad esempio, il numero massimo di file recenti di cui memorizzare il percorso) e quelle che dipendono strettamente dal s.o. e/o hardware (ad esempio l’uso di una particolare versione delle DirectX o delle OpenGL per sfruttare l’accelerazione hardware).
Per ambedue le tipologie si può utilizzare un apposito file di configurazione o chiave del registry, con il primo caso che è comune a tutti i sistemi, e il secondo che può prevedere delle precise istanze da utilizzare.
In teoria anche la distinzione fra file di configurazione e registry può essere eliminata, assumendo che una voce del registry venga mappata su un’apposita sezione del file, e viceversa. Sarebbe il s.o., in maniera del tutto trasparente, a occuparsi della conversione dall’uno all’altro, mettendo a disposizione delle apposite API da utilizzare proprio la gestione delle configurazioni.
Finora abbiamo parlato di dati da memorizzare nel cloud, ma è lecito anche pensare (e qualcuno, giustamente, l’ha già fatto notare nel precedente articolo) se il concetto possa essere applicato anche alle applicazioni, e in che termini.
Portarsi dietro i dati ovunque, configurazione inclusa, è decisamente comodo, ma ancora più comodo è se facessimo la stessa cosa anche con l’applicazione. D’altra parte servizi come il GMail ci hanno abituato a usufruire di entrambe le cose, in maniera semplice e trasparente.
Con un’applicazione “canonica” tutto si fa più difficile perché, al solito, c’è da pensare ai s.o e/o hardware diversi su cui deve girare. Quindi è fondamentale che la software house (o il singolo programmatore) forniscano appositi binari, ma ciò non è affatto diverso da ciò che succede oggi. Se Adobe non fornisce il suo Acrobat Reader per AROS/386, ad esempio, non c’è nulla da fare: non lo si potrà utilizzare su la versione x86 di questo specifico s.o..
Questo è sicuramente il più grande limite di una tecnologia cloud come quella che ho esposto in questa serie di articoli, e da questo punto di vista è inutile negarlo: i sistemi browser-centrici sono decisamente avvantaggiati, essendo il loro limite rappresentato dalla disponibilità di un buon browser, appunto, che bene o male si trova ormai per qualunque piattaforma (ma non è affatto scontato!).
Posto che i binari siano disponibili, nulla toglie di memorizzarli nel cloud in apposite locazioni, e demandare al s.o., al solito, il compito di recuperare quelli corretti per la precisa macchina su cui dovrà girare il programma, potendo anche contare sulla possibilità di aggiornamento automatico dello stesso qualora fossero disponibili dei binari più aggiornati.
E’ scontato che, a differenza dei dati e delle informazioni sulla configurazione, il canale su cui viaggiano i binari debba essere in chiaro. Non possiamo, quindi, pensare di poter criptare i dati, poiché l’algoritmo di codifica e l’eventuale chiave sono conservate gelosamente dal nostro s.o., per cui dal provider riceveremmo sostanzialmente spazzatura (perché applicheremmo la decodifica a dati non codificati, quindi codificandoli essenzialmente).
D’altra parte il protocollo di comunicazione coi provider non dev’essere affatto rigido. Abbiamo già individuato due scenari, quello dei dati e delle informazioni di configurazione, che richiedono un trattamento diverso, pur potendo usufruire della codifica dei dati trasmessi. Infatti nulla toglie che di un file possa essere codificato il solo contenuto, mantenendone in chiaro i metadati (primo fra tutti il suo nome).
In ogni caso il controllo di quel che transita rimane a carico del s.o., che può predisporre un’apposita sandbox in cui trasferire i binari, sempre avvisando l’utente dell’operazione e richiedendone il consenso per l’espletamento.
Gli scenari che vedo al momento per le applicazioni sono tre. Il primo riguarda l’uso del cloud come banale storage in cui piazzare i binari che ci servono, e sarà compito nostro indicare al s.o. dove andare a recuperarli, né più né meno di come faremmo coi dati.
Il secondo vede la partecipazione attiva del provider: è lui che mette a disposizione quanto serve, e l’utente non deve curarsi di null’altro di specificare quale provider vuole utilizzare, lasciando al s.o. il compito di analizzare quale applicazioni mette a disposizione, e scegliere quale installare (per la prima volta).
Ancora meglio sarebbe, visto siamo abituati a tenerlo ormai costantemente aperto, utilizzare il browser allo scopo, magari cliccando su un apposito link sul sito del provider/software house, che consenta di far partire la registrazione del provider (se già non è stata fatta) e l’installazione dell’applicazione che c’interessa.
Ovviamente il terzo scenario è simile al secondo, ma prevede il pagamento dell’applicazione. Quindi l’installazione può avvenire soltanto dopo che l’utente avrà fornito le necessarie credenziali, e lasciare, quindi, che il provider faccia proseguire l’operazione. D’altra parte non vorrete mica utilizzare Photoshop senza averlo regolarmente acquistato da Adobe prima, no? ;)
Credo che in mezzo a questi si possa ipotizzare qualche forma di applicazione adware. Nulla toglie, infatti, che eventuali banner pubblicitari vengano scaricati assieme ai binari, oppure recuperati da internet tramite la classica connessione aprendo un socket (ma sotto il controllo del firewall). Questo, però, è trasversale ai tre scenari ipotizzati, che riguardano più che altro il funzionamento intrinseco del protocollo cloud per le applicazioni che ne fanno uso.
Mi rendo conto che l’argomento cloud è molto vasto, e sicuramente non avrò considerato altre possibilità (magari i commenti serviranno a svilupparne altri), ma in questi articoli ho voluto esporre le mie idee su cosa mi aspetto da questa tecnologia, da fervido utilizzatore quale ne sono.
Spero che, quanto meno, il messaggio sia chiaro anche ai vari complottisti che cavalcano le facili onde degli allarmismi: cloud non equivale al controllo della privacy e/o a limitazioni della libertà. Come per tutti gli strumenti, ci sono pro e contro, scenari positivi e negativi: tutto sta all’uso che se ne fa. E questa, non v’è dubbio, è certamente un’ovvietà…
