Scritture (molto) asincrone

Ho appena aggiunto nella lista dei TODO per il progetto Hyppocampus la menzione al prossimo sistema di schedulazione delle scritture che vorrei implementare per supportare l'API di salvataggio "discreto".
Non ricordo se ne ho gia' fatto cenno qui, ma un riassuntino non guasta mai: l'idea e' quella di fornire in LibHyppo un set di funzioni che permettano di aggiungere ed eliminare dati pure nel mezzo di un file esistente, in modo da poter poi includere in Kiazma tutto il necessario per eseguire sempre e comunque salvataggi automatici a bassa latenza (nell'ordine di secondi) dei contenuti editati dall'utente all'interno dei widgets.
Il problema sta ovviamente nel fatto che le operazioni di scrittura nel mezzo di un file implicano lo spostamento sequenziale di tutti i blocchi che seguono, e sarebbe assai poco conveniente procedere con la riscrittura completa ad ogni byte cambiato; introducendo in Hyppocampus una sorta di coda di richieste, che scheduli i dati e le posizioni in cui vanno scritti, si dovrebbe riuscire a raggruppare ed ordinare tali dati ed eseguire accessi al disco un po' piu' consistenti ed efficaci, si' da sfruttare l'operazione di memorizzazione effettiva su ROM per far transitare piu' materiale in una volta sola.
L'effetto di tutto cio' sarebbe la disponibilita' di un sistema di salvataggio automatico in tempo reale, per cui ogni modifica ai contenuti viene mantenuta senza esplicita richiesta da parte dell'operatore: niente piu' pulsanti "Salva" o "Salva con nome", solo un costante salvataggio.
Maggiori dettagli a seguire.

LSQL?

Gia' avevo avuto in passato questa sensazione, ma stasera essa si e' fortemente rafforzata: il SQL non mi basta.
Sto scrivendo la routine che verifica se un item sul filesystem Hyppocampus rientra o meno nel result set specificato da una query, permettendo dunque un controllo senza obbligatoriamente andare a consultare il database (che altrimenti sarebbe interrogato da tutti i processi che fanno uso degli observers ogni volta che un metadato viene creato, rimosso o modificato) e mi rendo conto che, allo stato attuale, alcune particolari interrogazioni non sono possibili.
Non e' possibile confrontare due metadati per lo stesso item (data ultima modifica = data creazione + N), malamente sono trattati i metadati con valori multipli (quando ne testo uno confronto tutti i valori assunti o basta che uno solo soddisfi la condizione?), nessun controllo a priori viene fatto sul tipo di metadato e sul valore con cui viene confrontato...
Per la prossima release di Hyppocampus (non in questa, la 0.3rc2, che e' gia' sufficientemente in ritardo) vedro' di fare mente locale sulla situazione, e credo che finiro' a definire un mio proprio dialetto SQL con qualche operatore in piu' rispetto a quello tradizionale; gia' adesso alcune interrogazioni non sono possibili a causa della natura della base dati (non esiste DISTINCT, non sono selezionabili funzioni di aggregazione nella query primaria...), ma forse sarebbe opportuno porre dei paletti ben fissati e documentati sulle modalita' di ricerca.
Gia' oggi il parser che verifica e trasforma le query ha numerose lacune (gestito poveramente e' ad esempio l'operatore IN), provvedero' a ritoccarlo prossimamente e, soprattutto, a pubblicare una ricca specifica di riferimento.

Un VFS object oriented

Chi mi conosce lo sa: non sono mai stato un particolare fan dei linguaggi ad oggetti.
Ma, e questa e' una mia particolare considerazione pressoche' inedita, il design pattern della programmazione ad oggetti non mi dispiace poi troppo.
Ora che finalmente la parentesi del Linux Day e' stata chiusa (sebbene abbia ancora qualcosa da sistemare a tal merito... E debba poi tornare ad occuparmi di BarberaWare...), ho provato a riprendere in mano le modifiche iniziate due mesi addietro a LibHyppo e mi sono accorto che stavo compiendo un errore di progettazione: data per assodata la mia volonta' di portare in GObject tutte le strutture manipolate per mezzo di tale libreria, mi son chiesto "Ma perche' limitarsi a correggere le routine per il Virtual FileSystem solo per assecondare questa nuova formalizzazione? Adottiamo in toto la logica ad oggetti!".
Pertanto, da oggi (vabbe', diciamo domani... ;-P ) iniziero' a riscrivere il layer di astrazione per l'accesso ad Hyppocampus rifacendomi un po' meno all'abituale API descritta in POSIX ma sfruttando un po' di piu' le proprieta' stesse dei GObject.
Non garantisco di realizzare qualcosa di realmente ottimale (oramai si sa che il mio software difetta di particolare progettazione...), ma quantomeno un po' piu' vicino al modello object oriented pienamente supportato dallo stack Glib.
Tutto questo portera' ad una evidentente rottura dell'API, ma probabilmente non se ne accorgera' nessuno :-P

Thinking Kiazma

Leggendo questo per niente nuovo ma comunque sempre interessante articoletto sul multithreading (argomento su cui mantengo alto il livello di guardia) mi son ricordato che non ho ancora menzionato su questo blog gli ultimi progressi raggiunti nella fase di ri-progettazione di Kiazma, su cui ancora sto lavorando ma per cui vengo continuamente interrotto da altri impegni.
Assunto che il toolkit di riferimento sara' Clutter, il cui widget elementare da cui derivano tutti gli altri e' il ClutterActor, Kiazma avra' le interfacce KiazmaFile e KiazmaMetadata: la prima sara' implementata da tutti i widgets destinati a rappresentare a video elementi prelevati dal filesystem Hyppocampus (KiazmaIcon, KiazmaApplication...), la seconda da tutti i widgets destinati a rappresentare singoli metadati (KiazmaNote, e tutti gli oggetti editabili creati per ogni tipo di metadato previsto). ClutterActor "liscio" sara' usato per implementare widgets di contenimento (KiazmaIconView), prettamente decorativi o con scopi legati alle funzionalita' dell'applicazione in se' (KiazmaButton).
A dirla tutta non so ancora se KiazmaFile e KiazmaMetadata saranno interfacce o widgets da cui derivare poi gli altri, la prima soluzione permetterebbe di scrivere oggetti generici (da usare in ogni contesto, non necessariamente legato al filesystem) da estendere poi in altri oggetti che ne ereditino completamente le funzionalita' ed implementino solo le funzioni descritte dall'interfaccia, la seconda permette di mascherare meglio i dettagli che descrivo sotto; devo ancora analizzare le implicazioni delle possibili opzioni, ma piu' o meno la linea sara' questa.
Tra le maggiori novita' in questo sistema ci sara' una revisione che si spinge fino a LibHyppo, libreria che include il Virtual File System per l'accesso a Hyppocampus. HyppoVFSFile (il link si riferisce alla versione 0.2.3, che non e' piu' valida) diverra' un GObject (adesso e' una semplicissima struct) ed ogni istanza sara' monitorata, col supporto di SCD, per emettere signals in caso di modifica, aggiunta o rimozione dei contenuti o dei metadati assegnati: in questo modo, intercettando appropriatamente tali signals all'interno di KiazmaFile e KiazmaMetadata sara' possibile aggiornare dinamicamente la grafica presentata all'utente pressoche' senza intervento alcuno da parte del programmatore che sviluppa l'applicazione finale, rendendo implicita nel toolkit questa funzionalita'.
Quanto sopra descritto e' ancora completamente suscettibile di stravolgimento (vedro' di trovare un poco di tempo per meditare questo weekend), ma riassume a grandi (grandissime) linee quel che si vorrebbe ottenere per la serie 0.3 della componente grafica del progetto Lobotomy.