Building Blocks

Stufo di dover sempre ripopolare la mia installazione di Tracker ogni volta che per ragioni di debug la svuoto, e di dover andare a caricarmi qualche FeedChannel per testare miner-rss, ho incluso oggi in libgrss un parser OPML (prelevandolo come al solito da Liferea) e scritto due righe in croce per provvedere all'importazione dei files formattati in tal modo nello storage semantico. Il codice e' al momento pubblicato qui, alla meno peggio, ma penso che ne realizzero' una versione grafica in GTK+ da distribuire insieme a Phidias.
Attenzione, pero': "da distribuire insieme", non "incluso in".
La differenza sta nel fatto che questa micro-applicazione, se mantenuta come componente standalone, fungerebbe come importer OPML per qualsiasi feed reader basato su Tracker passato presente e futuro. Appunto perche' Tracker fornisce una rappresentazione univesale descritta dalle sue ontologie, cui tutti i programmi capaci di gestire MFO attingerebbero in modo trasparente.
Da innumerevoli anni sono sostenitore di una architettura di sistema basata su componenti specifici e mirati che possano integrarsi tra loro in modo naturale, dove qualsiasi miglioramento o nuova feature si ripercuota su tutte le applicazioni che rientrano appunto nella stessa architettura senza dover necessariamente ritoccarle tutte. Lobotomy, e piu' precisamente il SubConsciousDaemon, e' stato progettato esattamente secondo questo criterio. Ed ammetto che, nonostante i difetti propri della fuffa semantica, Tracker si presti a questo genere di utilizzo.
Per ora continuo la mia opera nella nicchia della gestione dei feeds RSS, aggiungendo qua e la' funzionalita' (o meglio: riadattando le funzionalita' esistenti), ma spero che il concetto di sistema "composito" possa essere apprezzato da qualcun'altro e applicato in altri contesti.

Mail, XML e Thumbs

Questo post non e' per un commento o una divagazione specifica e mirata, ma semplicemente per aggiornare i miei lettori sulle attivita' correnti. Del resto, se non ho tempo di bloggare e' perche' ho altro da fare.
Per conto di Itsme negli ultimi giorni ho dovuto "smontare" Evolution, il client mail di Gnome, e trarne una sorta di mail client batch, che non interagisca con l'utente per mezzo di una interfaccia grafica ma popoli il database del backend con le mail in ingresso ed intercetti le nuove mail create (sempre sul database) per spedirle. Al di la' del gusto intrinseco di codesta attivita' (andare a mettere il naso in qualche progetto open ha sempre il suo fascino...) la cosa interessante e' che, con qualche opportuno ritocco qua e la', codesto componente potrebbe divenire il primo pezzo concreto del SubConsciousDaemon di Lobotomy: il funzionamento e' esattamente quello che contavo di realizzare appunto per il mio ambiente, dunque tanto vale riutilizzare questo codice che sara' comunque prossimamente rilasciato in licenza free.
Sempre in merito a Lobotomy: sembra quasi incredibile, ma son tornato a lavorarci. Negli scorsi giorni ho ripreso in mano il dialetto XML per i Thoughts, per accertarmi del fatto che vengano coperti tutti i casi piu' comuni e che comunque non esistano limiti intrinsechi alla definizione di pressoche' tutte le "applicazioni" utili. A breve, terminati gli altri task gia' in corso (e descritti sotto) conto finalmente di iniziare Synapse, ovvero l'interprete del suddetto XML e piu' in generale il gestore dei templates.
Altrove sto ultimando l'opera sul generatore di thumbs dai contenuti di Gnome-Look.org: nonostante abbia avuto un po' da magheggiare per ottenere il risultato desiderato, in quanto i links dei temi da cui trarre la preview non sono fatti per essere trattati programmaticamente e negli archivi compressi i files sono organizzati spesso in modi totalmente arbitrari, e nonostante le limitazioni tecniche sul VPS su cui andra' poi a girare il sito (non son riuscito ad eseguire X.org non essendoci giustamente una scheda grafica, e senza X.org non si puo' lanciare il codice di generazione batch delle thumbs), il demone preposto al download ed all'elaborazione dei temi GTK e Metacity e' pressoche' pronto ed ora debbo solo rifinire l'interfaccia web del sistema. Una volta completata anche quella sottoporro' pure questo progetto al Social Desktop Contest, che ad un mese dalla chiusura conta un solo partecipante (me!) e da cui posso dunque sperare in una proclamazione: sembra la sceneggiatura di uno spot del Gratta e Vinci, quelli della serie "Ti piace vincere facile?", ma se cio' comporta l'acquisizione da parte mia di un netbook non me ne lamento.
Insomma, c'e' sempre qualcosa su cui lavorare...

Un Task per Domarli Tutti

Non nego che, sebbene continui a seguire la mailing list di sviluppo del progetto OpenMoko, da tempo abbia perso buona parte dell'interesse in merito a tale opera e solo di sfuggita legga le mail che transitano: troppo forte e' stata la delusione di avere tra le mani un FreeRunner completamente inusabile, e di vedere come OpenMoko Inc invece di darsi da fare per completare uno straccio di framework di sistema per il suo proprio dispositivo giocasse a mischiare tutto quanto ogni sei mesi ottenendo solo di spazientire la community.
Per un caso fortuito, seguendo il classico filone di links che rimandano da una news all'altra (sempre sia lodato l'ipertesto...), sono approdato alla pagina di uno dei componenti di cui piu' spesso ho visto menzionare il nome nella mailing list senza peraltro capire troppo bene di cosa si trattasse: Paroli. Assunto che non ho troppo ben capito come esso dovrebbe porsi nei confronti delle prossime versione della distribuzione OpenMoko (non doveva migrare tutto su Android???), di per se' il proposito mi sembra interessante; non fosse altro che e' lo stesso criterio con cui voglio costruire il prossimo SubConsciousDaemon!

Paroli (lemma che in esperanto significa "discussione": ottima scelta) non e' altro che un daemon di sistema il cui servizio e'... offrire servizi. In sostanza, wrappa l'uso di librerie e sottocomponenti rendendoli accessibili con una interfaccia (DBus) unificata, che descrive le operazioni piu' comuni e di interesse generale nel sistema (nel caso di OpenMoko: il networking, il GPS, il GSM...), permettendo di implementare una sola volta funzionalita' avanzate e renderle disponibili per tutti gli altri. Accentrando cosi' il codice prettamente funzionale si riduce la ridondanza di codice (da sviluppare, correggere e mantenere) e si induce al suo riuso ed alla creazione di inediti miscugli sinora non esplorati soprattutto per la complessita' della loro gestione.

Un poco alla volta, dunque, constato che la tendenza di accentrare le componenti funzionali di sistemi complessi isolandole e circoscrivendole dalle componenti grafiche si diffonde a si radica in sempre diversi frangenti: di anni dalla mia prima descrizione di tale architettura ne son passati assai, sono lieto che il tempo stia dando ragione (o quantomeno fiducia) a tale struttura. E non attendo altro che l'occasione di offrire la mia propria implementazione dell'idea, estremizzata all'interno del Progetto Lobotomy.
Non fosse per il fatto che tutto cio' e' in Python (linguaggio da me assai poco amato, e che a tutt'oggi mi domando e chiedo come si possa pretendere di utilizzare su un'apparato mobile con una potenza computazionale ridotta) potrei quasi pensare di riutilizzare tale componente all'interno della prossima incarnazione del mio personale progetto, correntemente in fase di progettazione e specificazione, ma e' probabile che esso sara' quantomeno fonte di ispirazione almeno per quanto riguarda la definizione dell'interfaccia programmatica con cui agganciare e rimuovere servizi e plugins.

Apriti Xesam

Ne avevo sentito parlare, me ne accenno' nuovamente l'amico Gigi tempo addietro, solo adesso ne guardo la documentazione. E non mi e' piaciuta.
Xesam si propone come uno standard per astrarre un qualunque storage di metadati (solitamente ad esso viene associato il ben noto Beagle, ma altri indexer sono gia' compatibili o sulla strada per esserlo) e permettere dunque a qualunque applicazione di attingere alla ricca base dati messa a disposizione; un ottimo esempio ne e' un curioso file manager che organizza i files in funzione della data di creazione...
Peccato che l'intera specifica dello standard sia... un protocollo XML! D'accordo che in questo modo si separa nettamente il formato dell'interrogazione dall'implementazione, e che dunque si puo' usare con qualunque linguaggio e nel modo piu' congruo a seconda dell'occasione, ma... Diamine: non esiste uno straccio di libreria di nessuna forma che implementi una qualsivoglia parte della specifica, non un esempio effettivo, l'unico punto di riferimento e' il codice gia' esistente (per lo piu' in C#... Mah...), e manco son riuscito a trovare una lista vagamente completa (e neppure abbozzata) di attributi che secondo il formato e' legittimo chiedere da una parte all'altra.
Mi ero proposto mesi fa' di rendere SubConsciousDaemon compatibile con lo standard, in modo da sfruttare la base dati di Hyppocampus appunto come collezione di metadati interrogabile da applicativi esterni, ma negli ultimi venti minuti mi e' quasi passata la voglia: con delle indicazioni del genere non so fino a che punto il formato si possa diffondere e radicare, e quanto possa realmente affermarsi nella prossima tornata di software desktop-oriented. A parer mio, o chi sa davvero come funziona la baracca (ed ha dunque le necessarie competenze) provvede a fornire qualche strumento piu' concreto che non una sommaria lista di tags XML piu' o meno validi, si' da incentivare l'utilizzo della tecnologia, o non si va da nessuna parte...

Uno, Nessuno, Centomila Linguaggi

La lettura di questo brevissimo articolo (trovato oggi su Slashdot) mi ricorda uno dei propositi che vorrei concretizzare nel prossimo futuro in SubConsciousDaemon: permettere la creazione di plugins in ogni possibile linguaggio di programmazione.
La realizzazione di per se' non dovrebbe essere complessa (basta creare un unico plugin che lancia l'eseguibile esterno e ne parsa l'output secondo un certo criterio predefinito... Brutale, ma rapido da implementare ed efficace), ma al di la' dell'utilita' o meno dello strumento ammetto che vorrei fare cio' anche e soprattutto per avere un modo (ed un pretesto) per scrivere un po' di codice in linguaggi diversi da quelli che sinora ho manipolato in modo semi-serio (ovvero: C, PHP, Java e poco altro).
Uno dei punti chiave di "The Pragmatic Programmer" (tomo menzionato anche nell'articolo sopra linkato, e di cui consiglio la lettura a tutti) e' appunto quello di sforzarsi per imparare almeno un nuovo linguaggio ogni anno, giusto per tenere la mente allenata e sufficientemente elastica per saper approcciare ogni sorta di problema secondo punti di vista diversi. Chiaramente, il suggerimento nasconde tra le righe un messaggio ben diverso che non "studia C++, Java, e Perl, PHP e Python ad oggetti": lo scopo dell'esercizio e' quello di affrontare diversi modelli di programmazione, che vadano oltre quella imperativa o ad oggetti, addrendrantosi magari nella programmazione funzionale, logica o di qualche altro tipo.
Sta di fatto che magari gia' stasera daro' una occhiata veloce ad Erlang, che viene citato da piu' fonti in special modo come linguaggio dedicato alla programmazione concorrente...