2 KiB
2 KiB
- Nell'attuale idea di implementazione l'arena riceve un payload JSON con il contenuto degli exams, uno per ogni partecipante,
il contenuto di un database #sqlite compostodal Collettore Probo (in questo momento rappresentato da un'applicazione locale). Il contenuto viene inviato dal Collector all'Arena mediante POST RESTdopo essere stato opportunamente codificato in base64. Il server Probo condivide con il collector (store) una API key.POST /create // []Exams => Exam store endpoint
- A partire dal db caricato, il collettore produce i test per i partecipanti.
- L'arena espone quindi un URL specifico per il test e raggiungibile dal partecipante il quale, in seguito ad autenticazione, potrà svolgere il test.
- Per consegnare l'URL al partecipante sono possibili diverse strategie.
- Un qrcode che codifichi l'url relativo al partecipante
- Un qrcode che codifichi l'url relativo al test
- Esempio: https://probo.land/{examID}
- L'URL del servizio che presenterà un campo di input dove inserire codice del test e a seguire codice del partecipante.
- In una prima implementazione, l'Arena funge anche da frontend per il partecipante. In un secondo momento si potrà pensare ad una separazione tra backend e frontend.
- La parte frontend dell'Arena dovrebbe consentire al partecipante di
- Revisionare le proprie risposte prima di inviarle
- Revisionare il risultato dopo la correzione
- La parte frontend dovrebbe consentire al partecipante di svolgere l'esame anche in assenza di connessione ad Internet utilizzando, per esempio, un sistema #CRDT.
- L'Arena dovrà essere in comunicazione con il collector al termine del test in modo che quest'ultimo possa raccogliere le risposte dei partecipanti ed eventualmente elaborarle. Arena e Collector saranno in comunicazione tramite API REST dopo essersi scambiati una API key. Inoltre, i due servizi potranno essere in comunicazione anche mediante #websocket per consentire uno scambio di dati in tempo reale.