Nelle pagine precedenti abbiamo avuto occasione di considerare come il processo di adattamento possa essere tanto più soddisfacente quante più informazioni si possono disporre circa il client, l'utente e il contesto in cui esso si trova. Tralasceremo, in questa guida, riflessioni circa i meccanismo di adattamento e di personalizzazione più generali e ci concentreremo sulla componente più strettamente tecnica.
Di seguito, forniremo una presentazione degli approcci più comuni relativi al riconoscimento del meccanismo di accesso. Esistono già diversi metodi per acquisire informazioni sul client. Si può affermare che essi vanno da una identificazione minima fino ad una descrizione pressoché completa delle caratteristiche del device.
Negoziazione mediante intestazioni HTTP
Il primo è più semplice metodo consiste nella lettura delle intestazioni HTTP inviate dal browser insieme alla richiesta della risorsa. Ogni programma di navigazione, oltre alla URL della pagina desiderata, trasmette in rete anche una serie di informazioni circa le proprie capacità e preferenze.
Lo standard HTTP 1.1 definisce una serie di intestazioni relative a cosa il browser è in grado o preferisce ricevere (accept headers):
- Accept: contiene i media types (MIME types) accettati dal programma
- Accept-Charset: contiene i set di caratteri riconosciuti
- Accept-Encoding: indica le codifiche di carattere rappresentabili;
- Accept-Language: elenca i linguaggi naturali preferiti dall'utente;
I valori di questi campi sono sufficientemente standardizzati per consentire un riconoscimento del client e - quindi - plasmare la risposta del server. Questo processo prende il nome di "negoziazione HTTP".
Altre intestazioni contengono il nome e la versione del programma. Nel caso dei dispositivi mobili, spesso, è presente anche una descrizione dell'hardware (dimensioni e capacità del display, per esempio). Tuttavia questi valori non godono della medesima standardizzazione incontrata negli accept headers. Diventa dunque complesso adottarli in una strategia di riconoscimento del client, dal momento che anche lo stesso browser potrebbe avere intestazioni molto diverse da una versione all'altra. Allestire uno script lato server che cerchi di utilizzare queste informazioni per adattare il contenuto potrebbe essere oneroso e poco efficace.
Un'utile strumento per ricavare gli header della richiesta HTTP è reperibile presso http://www.ericgiguere.com/tools/http-header-viewer.html . Per esempio, ecco alcuni headers trasmessi dalla copia di Firefox in possesso di chi scrive:
accept-language it,it-it;q=0.8,en-us;q=0.5,en;q=0.3
accept-encoding gzip,defilate
accept text/xml, application/xml, application/xhtml+xml, text/html; q=0.9, text/plain; q=0.8,image/png,*/*; q=0.5
accept-charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
user-agent Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
L'elenco complete delle intestazioni HTTP inviate dal browser è presente all'interno delle specifiche ufficiali del protocollo (http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3). Come si può notare, si tratta di un elenco relativamente ristretto e che, per ragioni tecniche, non può essere esteso arbitrariamente. Essendo necessarie molte più informazioni per condurre un adattamento più soddisfacente, sono stati elaborati altri approcci per la descrizione delle capacità del client. Un altro limite concerne l'efficienza: ad ogni richiesta del browser tutte le intestazioni vengono nuovamente inviate: sarebbe più vantaggioso accedere a tali informazioni una sola volta per tutta la durata della navigazione.
Tuttavia l'evidente e potente vantaggio di questo approccio è la rapidità di implementazione: è sufficiente conoscere le basi di un qualsiasi linguaggio di scripting server-side per allestire un algoritmo capace di effettuare un riconoscimento sulla base delle intestazioni HTTP. Per esempio, per chi programma in PHP esistono numerose classi opensource che provvedono ad eseguire tale riconoscimento, come mobileuseragent (http://freshmeat.net/projects/mobileuseragent/).
CC/PP, UAProf e WURFL
Per risolvere le limitazioni connesse alla negoziazione HTTP, il W3C ha approntato un'insieme di regole formali che dovrebbero consentire una descrizione più esaustiva ed efficiente delle capacità dei client. Questo strumento è denominato CC/PP, acronimo di Composite Capabilities/Preferences Profile .
CC/PP ambisce a definire un metodo standard per formulare la carta di indentità di un meccanismo di accesso. Fuor di metafora esso propone di utilizzare il formato RDF, il linguaggio designato dal W3C per aggiungere metadati alle risorse web. Essendo basato su XML, RDF è altamente estensibile e dunque rappresenta il formato ideale per descrivere risorse così eterogenee come i programmi di accesso al web.
Un profilo CC/PP è una collezione di attributi i cui valori possono essere utilizzati dal server per stabilire quale sia la risorsa più appropriata da inviare al client. Tale descrizione viene collocata in rete e possiede un identificatore univoco (URI): in questo modo il client non deve far altro che inviare il riferimento a tale identificatore e sarà compito del server recuperare le informazioni necessarie (adottando strategie di caching per ottimizzare la procedura).
È necessaria una precisazione: CC/PP non è un linguaggio, bensì un approccio che fornisce regole standard per la definizione di altri linguaggi di descrizione. Uno stesso dispositivo, quindi, potrebbe essere descritto secondo vocabolari differenti. La comune base offerta da RDF, comunque, è garanzia di traducibilità e di interoperabilità da un formato all'altro.
Al momento sono due le principali implementazioni di CC/PP.
La prima è stata formulata dalla Open Mobile Alliance (OMA) ed ha preso il nome di UAprof (User Agent Profile). Essa ha per scopo la creazione di un database di profili relativi ai dispositivi mobili. A titolo di esempio, forniamo i collegamenti ai profili di alcuni modelli di cellulare:
- Nokia 7650: http://nds.nokia.com/uaprof/N7650r200.xml
- SonyEricsson P900: http://wap.sonyericsson.com/UAprof/P900R101.xml
- Siemens S55: http://communication-market.siemens.de/UAProf/S55_05.xml
Un documento UAprof contiene informazioni riguardo a:
- Piattaforma hardware (dimensioni dello schermo, capacità audio, numero di colori visualizzabili ecc.);
- Piattaforma software (sistema operative, formati supportati ecc.);
- Rete (supporto per le diverse tipologie di connettività ecc.);
- Browser (nome, versione, linguaggi supportati ecc.);
- Caratteristiche WAP (versione di WML supportata, dimensioni massime dei deck ecc.);
- Possibilità di ricezione di informazione Push (come SMS, MMS, suonerie ecc.).
La presenza di simili file RDF in rete consente a client e server di disinteressarsi del contenuto specifico del profilo (che potrebbe essere anche aggiornato dal produttore in un secondo momento).
Una seconda implementazione di CC/PP è offerta da WURFL (Wireless Universal Resource File: http://wurfl.sourceforge.net ). L'iniziativa, nata dal lavoro degli italiani Luca Passani e Andrea Trasatti, mira a realizzare un file XML contenente i profili di tutti i dispositivi mobili conosciuti. Tale file può essere messo a disposizione di un'applicazione server ed essere consultato per prendere decisioni circa il miglior contenuto da inviare al client. WURFL è un progetto opensource: chiunque può inserire nuovi profili o modificare quelli esistenti aderendo alle specifiche del vocabolario di descrizione ( http://wurfl.sourceforge.net/help_doc.php ).
Analogamente a UAprof, anche questa seconda implementazione offre una descrizione delle capacità dei dispositivi, ma con una sintassi più semplice e intuitiva (è basata su un modello binario che indica la presenza o l'assenza di una data caratteristica). Le capacità dei dispositivi sono suddivise in venti gruppi ed è possibile giungere ad un livello di specificazione molto approfondito. Un altro aspetto interessante è dato dall'ereditarietà delle proprietà: dispositivi realizzati dal medesimo produttore, per esempio, possono avere in comune molte caratteristiche ed è quindi necessario indicare solo le peculiarità di ciascun device anziché ripetere per intero la descrizione.
