Cari tutti, a valle dell’incontro di ieri ho qualche spunto di riflessione da condividere con voi. Potrebbe trattarsi di idee parziali o non completamente rispondenti alla situazione reale, visto che non abbiamo ancora potuto testare la soluzione sul server. È probabile che, una volta risolto il problema di accesso alle risorse, ciascuno di noi ricercatori (anche con il supporto dei nostri esperti “amici” esterni) avrà ulteriori richieste. Da quanto mi è parso di capire, siamo messi molto bene con l’implementazione delle funzioni di una DAW (semplificata) in ambiente web. Se non abbiamo raggiunto il 100% degli obiettivi, ci siamo vicini. Rimangono in sospeso, invece, una serie di questioni relative all’uso condiviso del prodotto. Innanzi tutto, non abbiamo certezza che la soluzione basata su accessi concorrenti, in lettura e in scrittura, alla struttura dati centralizzata del progetto (un file JSON) regga a uno stress test. Tutto ci lascia immaginare che non sorgano problemi drammatici, ma – appunto – dobbiamo verificarlo sul campo. Questo problema è relativo alla parte sviluppata da noi del LIM, e ne siamo consapevoli, ma porta con sé alcune importanti conseguenze anche sul client. Innanzi tutto, come da specifiche, dobbiamo avere sul client un meccanismo di pull e push del progetto locale, e la cosa non è del tutto banale. Infatti, vi ricordo che l’utente deve ricevere, periodicamente o su richiesta, una copia del progetto centrale per allineare la sua versione locale, in modo da vedere in tempo differito le modifiche che altri utenti stanno apportando alle loro tracce. Ma la pull (intesa come allineamento della soluzione locale rispetto a quella centrale) non deve influenzare le tracce su cui l’utente sta operando localmente. Di converso, la push (intesa come allineamento del progetto centrale rispetto alle modifiche locali) deve riguardare solo le tracce su cui l’utente ha il lock (banalmente, quelle di sua proprietà). Una push intelligente, poi, allineerebbe solo le tracce su cui sono state operate modifiche rispetto alla precedente push, ma è una finezza su cui al momento possiamo soprassedere. Riassumendo: pull temporizzata e/o su richiesta esplicita, push solo su richiesta, il tutto ovviamente collegato ai nostri web services che devono correttamente gestire le chiamate. Un portato di queste considerazioni è che, sebbene il meccanismo di autenticazione sia compito di INDIRE, il client deve avere contezza non solo del progetto, ma anche dell’utente corrente. Al momento può anche trattarsi di una variabile stringa che funge da id dell’utente passata con il metodo GET al richiamo del client. Però tutto questo va gestito. Altro aspetto finora trascurato, almeno credo, è l’implementazione di un meccanismo di undo/redo sul client e di storicizzazione degli stati del progetto sul server. Come di consueto, la parte di vostra competenza è quella lato client, e anche qui potrebbe non essere banale decidere di quanto estendere undo/redo e su quali aspetti permettere di agire. Ad esempio, cosa deve succedere rispetto ai momenti di allineamento da remoto a locale (pull)? Personalmente, direi che undo/redo si applicano solo alle operazioni svolte in locale sulle tracce dell’utente, quindi quelle tracce non influenzate dalla pull. E cosa deve succedere rispetto a una push esplicita da parte dell’utente? A quel punto, direi di svuotare la lista degli undo/redo, soluzione molto pragmatica per non avere disallineamenti tra versione locale e versione centrale del progetto. Ma si possono anche fare scelte diverse, possibili in virtù del fatto che ogni utente rimane proprietario delle proprie tracce all’interno del progetto. Infine, mi chiedevo se sia stata implementata nel client la parte di visualizzazione e selezione dei campioni messi a disposizione da INDIRE, recuperabili attraverso la query sul database che vi ho girato. Infatti, la possibilità di “pescare” da quella libreria sarà una delle prime cose che INDIRE valuterà, e non potrebbe essere altrimenti, visto che i campioni audio in prima battuta potranno arrivare solo da tale collezione. Come nota a margine, vi ricordo la richiesta di poter caricare propri campioni, che implicherà la realizzazione di una maschera di caricamento per i file audio, il deposito sullo spazio web, la query di insert nel database e la gestione dell’utente/del progetto nel recuperare i campioni da mostrare. Non è una richiesta prioritaria, ma se qualcuno ci si potesse dedicare, faremmo una bella figura. Rimangono in sospeso le questioni grafiche, che sono però differibili nel tempo: il disegno della forma d’onda dei campioni, una qualche personalizzazione dell’interfaccia grafica a livello di foglio di stile, ecc. A presto. Luca