Esempi di applicazioni Odyssey

Per dimostrare l’utilit`a di Odyssey e l’effettivo vantaggio ottenibile tramite l’utilizzo di applicazioni adattive, gli sviluppatori hanno lavorato su quattro tipologie di applicazioni[43, 61], lavorando su programmi esistenti opportu- namente modificati per lavorare sul nuovo sistema operativo.

Per tutte le applicazioni sono stati effettuati test sulla fidelity ottenuta in caso di modifiche alla connettivit`a e sulla capacit`a di Odyssey di rispettare i requisiti di durata della batteria richiesti. Per questioni di spazio non

Client Xanim Viceroy Video Warden Video Server Odyssey API RPC

(a) Architettura del Media Player

Client Netscape Navigator Viceroy Web Warden Distillator Server Odyss ey API RPC Proxy HT TP HT TP to Web Servers

(b) Architettura del Browser Web

Client Anvil Viceroy Map Warden Map Server Odyssey API RPC

(c) Architettura del Visualizzatore di Mappe

Client Speech Front-End Viceroy Speech Warden Remote Janus Server Odyssey API RPC RPC Local Janus Server

(d) Architettura del Riconoscitore Vocale

Figura 3.2: Esempi di applicazioni in Odyssey

riportiamo i risultati dei test, che si sono comunque rivelati molto buoni anche per la durata della batteria, ma ci limitiamo a riportare gli esempi implementati, per dare un’idea dello sviluppo di programmi su Odyssey e degli esempi ben precisi di fidelity legata alle applicazioni.

Video Player In questo caso `e stata modificata una applicazione open- source preesistente: Xanim. Xanim `e un player multimediale per sistemi unix, che permette di visualizzare file locali. L’applicazione `e stata divisa in due parti, in modo da realizzarne una versione per file remoti. Il server remoto contiene i file gi`a preparati nelle varie forme di fidelity definite. In questo caso il warden richiede al server remoto un file con la fidelity impostata dall’applicazione, e lo invia ad essa. La struttura `e rappresentata in figura 3.2a.

1. Fidelity massima, video a colori con frame compressi in JPEG a qualit`a 99.

2. Fidelity media, video sempre a colori ma con frame compressi in JPEG a qualit`a 50.

3. Fidelity bassa, video in bianco e nero.

Mantenere i file compressi nelle tre versioni causa una occupazione maggiore sul disco del server del 60% rispetto al singolo file di dimensione massima. Con le tecnologie attuali si potrebbe comunque richiedere una codifica al volo al server e minimizzare l’utilizzo del disco.

Inoltre l’accesso al video avviene richiedendo i singoli frame. In questo modo il visualizzatore pu`o definire un secondo livello di fidelity, richiedendo un numero di frame al secondo minori rispetto a quelli totali del video. Per finire, un ulteriore grado di fidelity `e ottenibile codificando il video a varie risoluzioni, tecnica che si `e rivela molto utile soprattutto per il consumo energetico, in quanto diminuisce sensibilmente il carico computazionale del visualizzatore.

Web Browser Nel caso del browser web il grado di fidelity proposto si basa sulla variazione della qualit`a delle immagini presenti nella pagina:

1. Fidelity massima, immagine originale non ulteriormente compressa.

2. Fidelity medio-alta, immagine compressa JPEG con quali`a 50.

3. Fidelity medio-bassa, immagine compressa JPEG con quali`a 25.

4. Fidelity bassa, immagine compressa JPEG con quali`a 5.

Come esempio di browser web `e stato utilizzato Netscape Navigator. Al tempo il browser non era ancora open-source, perci`o le modifiche per rendere l’applicazione compatibile con Odyssey si sono rivelate molto difficili. La comunicazione tra browser e warden `e stata possibile attraverso un’ulteriore entit`a, utilizzata dal browser come proxy web, che si occupa di convertire le richieste HTTP in un formato compatibile col warden e di decidere i livelli di fidelity da utilizzare. Il warden comunica poi con un server remoto, che richiede le pagine da internet e ricomprime le immagini al volo in base alle richieste del warden. L’architettura finale `e presentata in figura 3.2b.

Questo esempio dimostra come adattare una applicazione binaria gi`a esi- stente ad Odyssey pu`o risultare molto difficile. Inoltre questi gradi di fidelity non comportavano modifiche sostanziali nel consumo dell’applicazione, in

quanto il codice del visualizzatore (Netscape Navigator) non era stato mo- dificato, e quindi la sua esecuzione non poteva trarre grosso vantaggio dalla diminuzione di qualit`a.

Visualizzatore di Mappe In questo caso gli sviluppatori hanno lavorato su un visualizzatore di mappe esistente, Anvil, di cui avevano i sorgenti. Il programma richiede una mappa da un server remoto, e la visualizza sul dispositivo. In questo caso l’applicazione (figura 3.2c) pu`o richiedere una mappa con meno dettagli al server oppure ritagliata ad un’area pi`u piccola, per diminuire la dimensione del file scambiato ed aumentare la velocit`a di disegno sullo schermo del PDA. Vediamo le possibilit`a di fidelity previste:

1. Fidelity massima, mappa a dimensione intera con tutti i dettagli pos- sibili.

2. Fidelity medio-alta, mappa a dimensione intera ma con la rimozione di alcuni dettagli (strade minori).

3. Fidelity media, mappa a dimensione intera ma con la rimozione di molti dettagli (tutte le strade secondarie).

4. Fidelity medio-bassa, mappa a dimensione ridotta con tutti i dettagli possibili.

5. Fidelity bassa, mappa a dimensione ridotta con la rimozione di alcuni dettagli (strade minori).

6. Fidelity molto bassa, mappa a dimensione ridotta con la rimozione di molti dettagli (tutte le strade secondarie).

Riconoscitore vocale Rispetto alle applicazioni precedenti il riconoscitore vocale lavora solo con dati locali, e non ha bisogno di un collegamento di rete per funzionare. Rispetto ai precedenti, per`o, non `e un semplice visualizzatore di dati ma ha bisogno di effettuare una computazione relativamente intensiva su quelli in ingresso.

I dispositivi wearable (almeno quelli esistenti al tempo) non hanno ri- sorse sufficienti per questo tipo di applicazioni; la soluzione proposta dagli sviluppatori di Odyssey `e di affiancare al software di riconoscimento vocale presente sul dispositivo mobile, una copia in esecuzione su un server remoto con adeguate capacit`a computazionali. In questo caso il dispositivo pu`o chie- dere un riconoscimento al server inviando i dati della registrazione. Il focus dell’adattivit`a si sposta quindi nuovamente sulle risorse di rete, che devono essere sufficienti al trasferimento della registrazione verso il server remoto.

In questo caso per diminuire il traffico `e possibile effettuare sul client una prima fase di preprocessing della registrazione, che diminuisce di 1/5 la dimensione dei dati da inviare sulla rete, al costo di eseguire una parte della computazione sul client.

Una differente soluzione prevede invece di effettuare il riconoscimento completamente in locale, ma su un vocabolario ristretto, tale da rendere la computazione fattibile anche per il dispositivo mobile. L’architettura ottenuta `e in figura 3.2d; le possibilit`a di fidelity le seguenti:

1. Fidelity massima, esecuzione remota senza nessuna elaborazione da parte del client.

2. Fidelity media, esecuzione remota con preprocessing da parte del client.

3. Fidelity bassa, esecuzione locale con vocabolario ridotto.

Tutte queste possibilit`a sono valide, soprattutto nell’ottica del risparmio energetico; infatti ridurre l’uso della cpu del client diminuisce il consumo ed aumenta la durata della batteria.