Gruppo TLW12

THC Clementino

L'applicazione è realizzata tramite librerie offerte dal framework dojo che offrono svariate funzionalità per garantire uniformità nell'interfaccia grafica e facilitare l'interazione con il server.

Accedendo all'applicazione, viene mostrata una schermata per la selezione del server su cui giocare. Ce n'è uno di default sviluppato dal nostro gruppo e altri due acquistati in fiera. Resta aperta la possibilità di scegliere un server arbitrario.
Tutte le richieste HTTP di tipo POST e GET verso il server avvengono in modo asincrono tramite l'oggetto XMLHTTPRequest.
Dopo aver scelto il server, appare una finestra con due tab, uno per giocare e uno per gestire l'organizzazione delle cacce.

Selezionando il primo tab, viene inviata la richiesta al server di gettreasurehunts, aggiornando così l'elenco delle cacce. Da questa schermata l'utente può selezionare una delle caccie, così da mostrare la descrizione della stessa. Dal menù contenuto all'interno del pannello contenente la descrizione, è possibile avviare le varie richieste verso il server. Il client tiene traccia di tutte le cacce dove l'utente è loggato. Quindi quando un utente sceglie di effettuare un'azione sulla caccia, viene mostrato un dialog per effettuarne il login. Il dialog di iscrizione/login permette di autenticarsi sia come utente facebook, sia come uno dei gruppi ai quali essi appartiene. L'utente può essere loggato su più cacce contemporaneamente con dati differenti, senza neccessità di inserire ad ogni operazione le credenziali di autenticazione.
Le varie operazione che l'utente giocatore può effettuare sono le seguenti, accessibili dai pulsanti della toolbar:

Dal lato amministratore sono possibili le operazioni di caricamento, rimozione, avvio delle cacce e richesta dello stato dei team. Viene chiesto all'utente di inserire dei dati di login, così da poter effettuare le operazioni suddette, senza reinserire ogni volta le credenziali.
Il caricamento delle cacce viene effettuato tramite un editor dove è possibile scrivere una caccia.

Su ogni risposta ricevuta dal server viene processato da un motore XSLT del browser. Se quest utimo è diverso da Internet Explorer o Firefox, la trasformazione viene delegata ad un servizio esterno creato appositamente.
Effettuiamo lo stesso metodo di delega ad un servizio esterno per la validazione dei documenti ricevuti dal server, dato che i browser non posseggono questa funzionalità.
In generale su ogni documento di risposta, dopo aver applicato la trasformazione XSLT, viene avviato il motore dojo che crea i vari oggetti in base ai vari elementi presenti nel documento. Per tutte le risposte, tranne per la gettreasurehunts, mostriamo un dialog che presenta all'utente il risultato delle varie trasformazioni.

Clementina - THS

Architettura

Le richieste sono effettuate via HTTP, con un approccio REST. In particolare tutti gli URL hanno la stessa struttura:

Il server è stato pensato modulare, con un'archettura REST per estenderlo facilmente in futuro.
Ogni richiesta viene analizzata solamente se e' un GET od un POST, dato che per ora nel protocollo erano presenti richieste di questo tipo. Le richieste e le risposte sono getsite dalla classe ReqHandler, si occupa della ricezione della richiesta e l'analizza inizializzando tutte le srutture dati neccessarie ad esaudire la risposta; successivamente viene utilizzata anche per spedire la risposta. Tutte le funzioni presenti nel protocollo sono implementate in una classe ThHandler, e vengono richiamate automaticamente in base al nome; in futuro se il protocollo dovesse venir ampliato basta semplicemente estendere questa classe con il nuovo metodo, e nel corpo principale del programma si specifica l'utilizzo della nuova classe handler Le impostazioni del server sono configurabili attraverso il file conf.xml, dove si può specificare: Tutti i dati vengono memorizzati in file XML, l'accesso a questi ultimi e' possibile utilizzando la classe XmlHandler che maschera all'utente l'utilizzo delle varie classi per la gestione dell'XML.

Scelte implementative

Struttura dei dati

I dati sul server sono stati strutturati pensando al fatto di avere svariate caccie al tesoro presenti contemporaneamente sul server. Questo implica che un utente deve avere prima possibile la risposta e mantenendo tutti i dati in un unico XML, si avrebbbe un collo di bottiglia dovuto al fatto che piu' utenti non possono aprire contemporaneamente lo stesso file. La cartella data e' strutturata in questo modo:
data.xml
/idCaccia/
th.xml
game.xml
user.xml
fhint.xml
/.../

Il file data (validato da questo XML schema) e' il file principale che contiene le informazioni generali su tutte le caccie al tesoro, tra cui l'organizzatore di ogni caccia, ed i dati richiesti dalla funzione gettreasurehunt; quando si richiama quest'utlima funzione non serve bloccare l'accesso a tutti i file che descrivono ogni caccia, tutte le informazioni neccessarie sono qui.
Il file th (validato da questo XML schema) contiene tutte le informazioni inviate dall'organizzatore riguardo alla caccia al tesoro. Praticamente ridefiniamo l'elemento thunt specificato nel protocollo aggiungendo ad ogni turno ed ad ogni hint un identificativo.
Il file game (validato da questo XML schema) contiene tutte le informazioni relative al gioco in corso. Per ogni giocatore tiene traccia del turno e degli hint ricevuti e dell'ora in cui sono stati rilasciati dal server.
Il file user (validato da questo XML schema) contiene tutte le iscrizioni degli utenti alla caccia al tesoro.
Il file fhint (validato da questo XML schema) contiene tutti i falsi indizi che in una caccia trasparente gli utenti possono inviare.

Gestione ID

Qualsiasi caccia, turno, indizio e ogni falso indizio deve essere identificato univocamente altrimenti rischiamo di restituire dei dati inconsistenti. Per fare questo quindi si è scelto di creare i vari ID utilizzando l'algoritmo MD5. Per evitare ugualmente possibili collisioni ogni per ogni id l'MD5 viene fatto anche su parametri sempre diversi.

Accessi concorrenti

Per mantenere i dati consistenti abbiamo dovuto gestire l'accesso concorrente alle varie risorse. PHP ha una funzione apposita, flock putroppo però non funziona su tutti i filesystem, ed in particolare su NFS non garantisce la gestione corretta dei lock. Questo filesystem l'atomicità la garantisce solamente per la creazione delle cartelle e dei link simbolici, per questo nel file di configurazione possiamo specificare se utilizziamo NFS e il server adotta un meccanismo basato sulla creazione di cartelle apposite di lock.