16
Project Lobotomy Essentials, parte III: LibHyppo
marzo 2008 da Lobotomia
(Non ancora votato) 
Loading ...
Nello scorso brano della serie abbiamo visto il filesystem relazionale Hyppocampus, ma in merito ad esso non abbiamo detto una cosa fondamentale: la sintassi di interrogazione e’ assai complessa, e, al fine di mantenere coerente e semplicemente mantenibile il parser interno, ogni elemento della query (i metadati richiesti, i valori che devono corrispondere…) deve essere espresso secondo rigidi, inflessibili e ben poco mnemonici parametri.
Per facilitare l’accesso alla base dati viene dunque fornita, insieme al pacchetto del componente, una libreria che implementa un layer di astrazione con una discreta API che permette la rapida costruzione di applicazioni che sfruttino appieno lo storage relazionale: tale libreria e’ LibHyppo.Nella serie 0.2.x dello sviluppo LibHyppo includeva un insieme di funzioni che ricalcavano le classiche syscall POSIX per l’accesso al filesystem, per l’apertura delle cartelle (che in realta’ sono generate on-the-fly in funzione dell’interrogazione sottoposta) e l’accesso ai files, ma gia’ permetteva di esprimere le query secondo un linguaggio meno formale (usando i nomi dei metadati anziche’ i loro identificativi numerici) e vicino all’utente, provvedendo internamente alla trasformazione.
Dalla serie 0.3.x a questo set elementare, in buona parte comunque mantenuto, e’ stata affiancata una API object-oriented costruita sfruttando la libreria GObject (facente parte del pacchetto Glib, parte integrante dello stack software di GTK+), in cui ogni meccanismo di accesso al filesystem viene mascherato da “oggetti” che rappresentano le diverse sfumature relazionali logicamente estratte dal filesystem: troviamo dunque il HyppoVFSSet, che implementa un result set e contiene un gruppo di HyppoVFSItem’s, i quali a loro volta rappresentano singoli files e gestiscono internamente una lista di HyppoVFSMetadata, ovvie controparti di alto livello dei singoli metadati. Seguendo questo approccio e’ assai piu’ comodo per lo sviluppatore accedere, manipolare e trasformare le informazioni tratte da Hyppocampus, lasciando alla libreria il compito di interrogare, tenere una cache, scrivere permanentemente su disco e molto altro.
Degno di nota e’ il trattamento delle notifiche in tempo reale dei cambiamenti avvenuti sul filesystem, incluso nella piu’ recente release del pacchetto (0.3rc2): per mezzo di D-Bus (il daemon di inter-process communication che si sta affermando come standard nel desktop Linux), e passando per SubConsciousDaemon (componente dell’ecosistema Lobotomy, che si approfondita’ nel prossimo articolo), ogni singolo oggetto sopra menzionato e’ logicamente connesso ad Hyppocampus, e, secondo la specifica GObject, rilascia “signals” in occasione di particolari variazioni intercettate sul disco; tali signals possono essere agganciati ad alto livello a callbacks destinate, a seconda della necessita’ e della natura del programma, ad aggiornare la grafica di presentazione all’utente o attivare funzionalita’ in cascata.
Ad esempio, un qualunque HyppoVFSSet viene notificato e notifica il resto del processo ogni qualvolta un item ricade nella query da esso rappresentata, magari perche’ gli e’ stato assegnato un nuovo metadato da un altro programma ed il valore matcha l’interrogazione. Vediamo dunque come in tre passaggi (”SELECT WHERE type = ‘mail’ AND sender = ‘pippo’”, registrazione di una callback, e riproduzione di un file audio), rapidamente ed intuitivamente si realizza una applicazione che ci notifica sonoramente dell’arrivo di posta elettronica dall’amico preferito di ogni developer.
Per ulteriori dettagli su LibHyppo si rimanda alla pagina dedicata al filesystem Hyppocampus: http://lobotomy.sf.net/Hyppocampus.php.
Nel prossimo articolo, un approfondimento sulla componente di estrazione automatica dei metadati inclusa attualmente in Lobotomy.
Post correlati
Categorie: Desktop
Tag: D-Bus, Desktop, GTK, Linux, Lobotomy, Sviluppo
