L'Indirizzo che non C'e'

Leggendo l'ennesimo apocalittico articolo in merito all'allocazione dell'ultimo blocco di indirizzi IPv4 disponibili, e memore di alcune osservazioni che io stesso ho fatto in un post dell'altro mio blog a sfondo "culturale", mi sono capacitato di una emergenza imminente nel campo dell'interazione uomo-macchina: quando IPv6 sara' la norma, e anche la mia LAN sara' routata su tale protocollo, come diamine faro' a ricordarmi a memoria gli astrusi ed assolutamente poco mnemonici indirizzi delle macchine di casa mia per potervi accedere? Bene o male con IPv4 ci si arrangia, assunto che la classe di una rete domestica e' quasi sempre una di quelle appositamente lasciate riservate per scopi locali (o, per meglio dire: e' quasi sempre 192.168.0.0), ed anche un identificativo arbitrario sulla Rete globale e' pur sempre costituito da soli quattro numeri che con un poco di sforzo si riescono a fissare nel cervello, ma chi mai potrebbe memorizzare la sfilza di caratteri, cifre e segni di interpunzione mescolati in un indirizzo di nuova generazione? Certo, anche in IPv6 esiste il concetto di indirizzo privato che puo' essere espresso in forma abbreviata, in cui comunque si trovano ben 10 cifre esadecimali a caso; un numero in base 10 (ad esempio: 134) si ricorda sicuramente meglio di un agglomerato impronunciabile (ad esempio: 21F4).

Il problema e' piu' grave di quanto non si possa immaginare, in quanto a tutt'oggi ci troviamo a maneggiare gli indirizzi numerici piu' spesso di quanto non si creda.

Per individuare e navigare i filesystem delle altre macchine nella rete locale, esposti con i protocolli piu' disparati (NFS, NetBIOS/Samba, SFTP...), esistono gia' fior di tools perfettamente integrati con ogni desktop environment minimamente completo (cfr. Gnome e KDE). Dunque in questo caso il dubbio non esiste. Lo stesso puo' dirsi per le stampanti (nativamente di rete, o esposte in rete per mezzo di CUPS). Ma quanti sono gli strumenti di backup, con cui periodicamente duplicare i propri dati importanti su un altro PC e/o un altro disco rigido remoto, che supportano il discovery delle istanze sparpagliate sul network? E come fare a trovare le interfacce di amministrazione web dei vari routers, access point e modem che popolano le mensole polverose delle nostre case? Senza parlare di tutte le esigenze assai piu' complesse degli utenti piu' smaliziati, i quali tanto per dirne una hanno questa fissazione di accedere ai propri PC via SSH...

Le odierne limitazioni dei meccanismi di amministrazione delle reti, unite alla crescente necessita' di essere connessi all'Internet ed alla moltiplicazione di apparecchi digitali di cui ognuno dispone (ben poche sono le case in cui ci sia un solo PC, senza contare smartphones e tablets ed altre diavolerie), implicano che l'interazione diretta con gli indirizzi IP e' oramai pratica assai diffusa e pervasiva, anche tra l'utenza di basso rango: negli ultimi mesi mi e' capitato piu' di un utonto contemplare il relativo pannello di configurazione sul proprio sistema operativo alla ricerca di una soluzione abbozzata per potersi agganciare ad un vicino access point, spinto e motivato in questa sua estemporanea avventura nerd dal desiderio di consultare la propria bacheca su Facebook.

Siamo davvero pronti a questo salto? Gli strumenti di assistenza per i quotidiani task relativi al networking (locale e remoto) sono all'altezza? Mi piacerebbe metterli alla prova, switchando la mia LAN appunto al routing IPv6, non fosse che la versione di dd-wrt flashata sulla mia Fonera non supporta tale protocollo e non riesco a fare l'upgrade alla versione successiva: partiamo subito male...

Aggiornamento nell'Ombra

Manco il tempo di finire di scrivere il precedente post sui potenziali vantaggi di un meccanismo di aggiornamento interno alle applicazioni, in grado di pescare autonomamente informazioni sulla disponibilita' di nuove versioni da scaricare ed installare in modo trasparente e senza disturbare l'utente, che subito salgono agli onori della cronaca notizie sulle prossime evoluzioni di Chrome, il web browser targato Google.

Stando alle ultime presentazioni per il prossimo futuro di tale prodotto si prevede di soppiantare la tendenza prettamente tecnofila di rilasciare le varie versioni identificandole da un numero sequenziale, ed invece impacchettare piccoli cambiamenti ad intervalli regolari e tra loro ristretti (sei mesi) e diffonderli sui desktop del pianeta con un automatismo silenzioso. A ben guardare Chrome da sempre gestisce in questo modo gli aggiornamenti di se' stesso, addirittura compiendo un controllo sul repository centralizzato ogni cinque ore, ma evidentemente il concetto e' stato migliorato e raffinato ulteriormente. Si mormora inoltre che pure la prossima major release di Firefox, la 4 includera' tale funzionalita'.

Come intuibile, appunto, dal post pubblicato l'altro giorno su questo stesso blog questo genere di soluzioni mi garba assai. Tantopiu' per applicativi come i web browser, diventati strumenti essenziali nella vita digitale di ciascuno e cosi' frequentemente bersagliati da attacchi mirati alla loro sicurezza da patchare il piu' presto possibile a prescindere dalla noncuranza dell'utente. Certo chi sviluppa un browser non ha tutta questa urgenza di diffondere nuove features, in quanto in fin dei conti tale classe di software operativo non espone particolari funzionalita' necessariamente sempre nuove (renderizzano le pagine, salvano i bookmarks, aprono e chiudono le tabs, poco altro), ma le migliorie per quanto piccole e discrete son sempre gradite, soprattutto quando non ci si deve attivare in prima persona per ottenerle.

D'altro canto, immagino che nel momento in cui i singoli programmi provvedano per conto proprio all'aggiornamento si possano creare non pochi grattacapi per i packagers delle distribuzioni. Cosa mettere nei repository? Cosa succede se all'atto dell'invocazione di un "apt-get upgrade" la versione proposta e pacchettizzata e' piu' vecchia di quella scaricata autonomamente? Come fronteggiare eventuali aggiornamenti che richiedono librerie e pacchetti particolari, e dunque da installare o a loro volta aggiornare per il supporto di una nuova funzionalita'?

Per non parlare dei futuri (ma comunque non immediati) problemi tecnici che potrebbero sorgere qualora tale pratica dovesse diffondersi: come arginare la potenziale esplosione di comunicazioni verso l'Internet, dovute al fatto che ogni singolo programma pretenderebbe di contatterebbe ad intervalli periodici il proprio server di riferimento in cerca di qualcosa di nuovo da scaricare? E come reagirebbe quella nicchia di utenti cultori della privacy e del pieno controllo dinnanzi alla necessita' di dover disabilitare (o nella peggiore delle ipotesi filtrare con metodi piu' radicali) siffatte transazioni non richieste per ognuno dei software utilizzati?

La soluzione ad entrambi i suddetti tipi di ostacoli potrebbe stare in una evoluzione degli attuali package managers, affinche' forniscano nativamente la funzionalita' di auto-upgrade per i programmi che lo richiedono, coordinando ed ottimizzando le connessioni verso l'esterno e provvedendo un unico centro di configurazione per chi ha il tempo da perdere verificando chi sta facendo cosa. Dirottando tutto al manager centralizzato esso sarebbe sempre consapevole di quale precisa versione e' in uso in un dato momento, quali sono i pacchetti che si auto-aggiornano per fatti propri e quali devono essere allineati con i repository della distribuzione secondo lo schema classico, e come comportarsi con le dipendenze.

Forse adesso e' troppo presto per porsi questo genere di domande, in quanto appunto solo Chrome e Firefox si stanno muovendo verso la direzione dell'autogestione. Ma nel momento in cui dovesse essere osservato un trend piu' cospicuo sarebbe opportuno correre ai ripari il prima possibile, mettendosi d'accordo tutti insieme su come amministrare in modo pacifico la legittima richiesta di aggiornamenti frequenti con la necessita' di far convivere numerosi pacchetti ognuno con una propria sequenza di versioning, ed evitare che codesta emergente moda dilaghi fino a minare uno dei pilastri su cui si poggia il successo del desktop Linux, appunto il package management.

Prevenire e' meglio che curare.

Zero Upgrade

Nel precedente post ho fatto menzione alle comodita' programmative dell'usare una rappresentazione "uno a uno" degli oggetti manipolati ad alto livello con lo schema del proprio database: poco codice che gestisce tutto quanto, logica abbastanza lineare e necessariamente coerente dunque comprensibile, grande flessibilita'...

Qui vorrei fare una rapida menzione ad un ulteriore vantaggio di questa strategia, che ho l'altro giorno implementato e perfezionato nel codice del mio gestionale per gruppi di acquisto: l'aggiornamento automatico e trasparente del database in caso di upgrade dell'applicazione.

Passando dalla release 1.0 alla release 2.0 mi sono posto il problema di rendere l'upgrade di GASdotto semplice, almeno tanto quanto lo e' l'installazione, ma ho sicuramente fatto le cose un po' di fretta e mi son ritrovato un garbuglio di "ALTER TABLE" che certamente non avrei potuto mantenere anche nella futura release 3.0 (dovendo peraltro gestire i casi di migrazione partendo da 1.0 o 2.0). Alche' mi sono ingegnato ed ho deciso di spremere meglio la mia mappatura degli oggetti sul database, implementando l'operazione inversa: costruire il database partendo dalle classi PHP.

La funzione che effettua davvero le query (resa unica in tutto il programma originariamente con l'intento di centralizzare la gestione degli errori) e' stata modificata in modo che, se una richiesta verso il database fallisce, prima di tentare una seconda volta verifica che tutte le tabelle siano al loro posto e che esse abbiano tutte le colonne che descrivono gli attributi dei miei oggetti PHP di alto livello. L'effetto collaterale di tale meccanismo e' ovvio: GASdotto non abbisogna piu' di una procedura esplicita di upgrade, basta decomprimere l'archivio compresso al posto del precedente (magari salvandosi prima il file di configurazione) e al primo login si arrangia da solo nel modificare il database allineandolo alla struttura richiesta con le nuove colonne e le nuove tabelle.

La procedura deve ancora essere testata con cura, ma i primi esperimenti sono stati soddisfacenti: trovandomi adesso ad attuare qualche correzione alla gestione delle notifiche mi trovo a dover aggiungere qualche attributo alla classe Notification, e laddove prima dovevo rimaneggiare la classe PHP, quella Java e lo schema del database, adesso metto mano solo al codice e la prima volta che ricarico l'applicazione nel browser la query fallisce, esegue il controllo, crea le nuove colonne richieste nelle tabelle e tira dritto.

Sebbene il tutto sia ancora migliorabile (manca la definizione dei valori con cui inizializzare le eventuali nuove porzioni di database) posso ritenermi soddisfatto di questa novita': ho eliminato un passaggio richiesto per l'amministrazione dell'applicazione da parte degli utenti (spianando peraltro la strada ad un futuro automatismo per l'aggiornamento trasparente, come quello gia' esistente nell'ottimo Wordpress), ed io ho ridotto la quantita' di cose di cui preoccuparmi durante lo sviluppo.

Regola 1: essere pigro, e far fare alla macchina quello che non si ha voglia di fare a mano.

Mappa Geo/Mentale

Qualche tempo addietro il buon Seif Lofty, maintainer dello stravagante progetto Zeitgeist, ha pubblicato un esempio di cio' che e' possibile fare appunto con il suo collettore di informazione.

In una applicazioncina, approntata a mo' di hack, viene presentata una mappa geografica, e cliccando su di essa vengono visualizzati i files editati o consultati mentre ci si trovava in tale posto. O anche, come dimostrato nello screencast, le persone con cui si ha chattato stando in tale locazione.

Il concetto mi garba assai, perche' aggiunge un ottimo criterio di ricerca per facilitare l'individuazione dei files cui si e' interessati: lo spazio fisico. Accade infatti piu' spesso di quanto non si creda (almeno a me) di ricordare di aver fatto o visto qualcosa di interessante mentre ci si trovava in un dato luogo, magari a casa di un amico o nel bel mezzo di un raduno di smanettoni, e nel suo piccolo codesto simpatico software si presenta come ottimo connubio tra facilita' d'uso ed efficienza del risultato.

Dal canto mio avevo gia' iniziato a valutare tempo addietro questo genere di correlazioni "ambientali" per facilitare la navigazione dei contenuti, tant'e' che nella lista di possibili Thoughts per Lobotomy avevo immesso anche una fantomatica "Timeline" che mettesse in parallelo l'accesso ai documenti con altri parametri apparentemente totalmente scorrelati tipo gli eventi del calendario (per sapere cosa e' stato consultato mentre ci si trovava ad un dato appuntamento, concetto gia' superficialmente implementato dal file manager Nemo) o addirittura le condizioni meteo ("L'altro giorno pioveva e ne ho approfittato per scrivere quel file, dove l'ho messo...?").

Piu' in generale credo che tale genere di espedienti multisensoriali siano una ottima strada da esplorare nella corsa al data management moderno, in questi tempi cosi' ricchi di materiale da gestire e cosi' scarsi strumenti per farlo. Il fatto di estendere le capacita' di ricerca entro una dimensione, appunto lo spazio e le condizioni fisiche, cui il nostro cervello e' assai ben abituato da qualche centinaio di migliaia di anni di evoluzione e' un inestimabile valore aggiunto, esattamente perche' rende l'operazione di ricerca estremamente piu' naturale.

Si avvicina il momento in cui l'odierna gerarchia a cartelle sara' sostituita da qualcos'altro, magari una cartina geografica...

Faldoni VS Database

L'altro giorno mi sono recato con un amico presso un piccolo produttore agricolo con lo scopo (che non intendo qui approfondire nel dettaglio) di appurare come utilizzasse lui il computer nello svolgimento delle sue pratiche burocratiche e produttive. Ne e' emerso uno scenario perfettamente prevedibile e scontato, ma non per questo meno disarmante: il PC viene usato pressoche' esclusivamente come macchina da scrivere, per compilare bolle e fatture da stampare e maneggiare poi analogicamente (= su carta).
L'apoteosi dello sconforto l'ho raggiunta quando il suddetto agricoltore (lui, come lo potrebbe fare la stragrande maggioranza dell'utenza informatica di basso livello odierna) ha apertamente ammesso che il computer, massima espressione della scienza tecnologica nella sua esistenza rurale, e' un problema inevitabile piu' che una soluzione desiderabile: difficile da usare, incomprensibile, caotico, con l'unico pregio che con un paio di copia&incolla si velocizza qualche sporadica operazione nella compilazione dei moduli che se altrimenti fatta a mano richiederebbe piu' tempo. Mentre diceva cio', io guardavo il vicino armadio carico di faldoni e carte accumulate dopo essere uscite dalla stampante del vituperato marchingegno digitale, certamente perche' il personaggio riesce meglio a scartabellare e cercare cio' che gli serve su supporto fisico anziche' tra le cartelle virtuali del filesystem.
Del resto, neppure mi sento di dargli tutti i torti: il computer ha un costo, cosiccome la licenza di Excel installata sopra (suppongo sia stato originale, acquistato in bundle con la macchina numerosi anni addietro, e se anche fosse stato pirata glielo ha installato qualche pseudo tecnico in qualche negozietto di informatica facendosi comunque pagare per il disturbo), e tale applicativo viene usato per compiti ben piu' complessi ed avanzati che non quelli per cui e' stato ideato. L'acquisto di un software specifico per la sua attivita' costerebbe 3000 euri (e non e' una stima: il programma esiste davvero e gli e' stato offerto esattamente a quella cifra), e per esperienza gia' so che si tratterebbe comunque di un accrocchio Visual Basic + Access messo in piedi alla meno peggio con lo scopo esplicito dell'azienda produttrice di trarre profitto ulteriore con i corsi per sommariamente imparare ad usarlo e l'assistenza. Pertanto ci si arrangia con quel che si ha, ovvero qualche programma realizzato da vendors diversi tra loro nient'affatto integrati, con interfacce diverse e carichi di features introdotte per giustificare le nuove release, e appena possibile si ricorre al tasto "Stampa" per portare le informazioni importanti fuori dal ronzante scatolone di plastica e alluminio.
Non oso neppure immaginare cosa la piu' scarsa e umile tecnologia digitale oggi esistente potrebbe realmente fare per quest'uomo: i dati, se immessi in un database, potrebbero essere spulciati e tra loro intersecati con dettaglio estremo in pochi secondi; le anagrafiche di fornitori e clienti, se formattate in hCard e gestite direttamente dagli interessati, potrebbero essere pescate dall'Internet ed aggiornate automaticamente, e istantaneamente accessibili digitando tre caratteri del nome; i documenti potrebbero calcolarsi per conto proprio quantita' totali, prezzi totali, IVA e altri parametri burocratici partendo da pochi valori relativi alla merce ricevuta o da consegnare; gli stessi totali potrebbero essere trasmessi al commercialista in formato digitale, e questo potrebbe a sua volta importarli nel suo proprio programma per farci quel che deve farci; i pagamenti, se trasferiti per via telematica, sarebbero usati seduta stante per computare bilanci ed introiti (o al contrario innescare sollecitazioni automatiche se non arrivati in tempo). Senza parlare del risparmio di carta, inchiostro e spazio.
Se nell'Anno Domini 2010 tutte le attivita' produttive e commerciali ancora non hanno trovato nella tecnologia un valido ed appropriato supporto la causa non e' solo delle ovvie resistenze riscontrate presso il grande pubblico nei confronti delle novita' ma anche e soprattutto da imputare a coloro che dovrebbero provvedere alla messa in opera di questi semplici e talvolta persino banali (per un tecnico, intendo) strumenti, e che speculano sulla scarsa consapevolezza e dimestichezza dei propri clienti per spremere ogni singolo centesimo dalla loro ingenuita'.
Le cose possono cambiare. Devono cambiare. Poche righe di codice, se stese con criterio, possono allo stesso tempo ridurre il tempo (e dunque il costo) necessario a svolgere una operazione, aiutare a massimizzare i profitti incentivando particolari scambi monetari, e salvare un albero destinato a diventare carta da stampa. E' venuta l'ora di iniziare a scriverle.

TuxChan

Come sempre con l'approssimarsi delle vacanze estive, mentre amici e colleghi partono per trascorrere le ferie nei posti piu' disparati, io colgo l'occasione per sviluppare in santa pace un po' di software per conto mio. Sebbene dovrei lavorare su Lobotomy (ho finalmente iniziato la scrittura del parser di Synapse!), o dare qualche sistemata a GASdotto in vista della messa in opera prevista per settembre, o rifinire libopengdesktop ed aggiungere la pletora di funzionalita' ancora mancanti, in atmosfera vacanziera e di spensieratezza ho ben pensato di dedicare un pochino di tempo ad un ennesimo progettucolo: TuxChan.
La storia del perche' e percome sia arrivato a tale ispirazione la rimando ad un'altro post, per ora mi concentro sull'aspetto tecnico: esso e' un client desktop per 4chan, la popolare imageboard che dal 2003 convoglia il peggio del peggio del cazzeggio e da cui storicamente emergono alcuni dei piu' virali e devastanti meme.
In cosa consiste 4chan? In un sito estremamente brutto ed inutilizzabile in cui nei vari canali tematici si svolgono discussioni incentrate per lo piu' intorno alle immagini postate dagli utenti, ed in cui i contenuti vengono automaticamente cestinati via via che ne arrivano di nuovi. I materiali variano entro un range abbastanza vasto, non esistendo regole o comunque essendo moderatamente rispettate e non vigilate, il file rouge sembra essere il Giappone (Terra Promessa di molti geeks occidentali) ma nella stragrande maggioranza dei casi si tratta di fotografie divertenti (quantomeno secondo la cultura internettiana) oppure a sfondo sessuale.
A cosa serve 4chan? Assolutamente a nulla, se non a far perdere un po' di tempo ai giovanotti col pallino delle giapponeserie e senza nulla di piu' utile da fare che non stare a contemplare lo stream di immagini che freneticamente si susseguono sulle sue pagine.
E dunque, a cosa serve TuxChan? Agli utenti, ad avere una interfaccia un pochino piu' decorosa dell'originale e nella possibilita' di ricevere indirettamente i push sugli aggiornamenti senza stare a ricaricare manualmente la pagina web ogni due minuti (ed all'interno delle community che orbitano intorno a questo tipo di contenuti essere i primi a venire a conoscenza di qualcosa di nuovo e condividerlo con i pari gioca un ruolo sociale non secondario). A me, ad avere un pretesto per giocare finalmente un po' con Clutter.

Da tempo immemore cercavo un qualche applicativo che mi permettesse di mettere alla prova il toolkit, e non potevo scegliere momento migliore che non il recente rilascio della release stabile 1.0. E non mi sembra affatto male: nel giro di un paio di serate (in buona parte buttate appresso a GIO: non usate g_file_copy_async() !!!) e nello spazio di meno di 1000 righe di C (altro argomento su cui dovro' tornare prossimamente) ho ottenuto una interfaccia a parer mio soddisfacente, minimale e proprio per questo efficiente, con le immagini che scorrono ed un pannellino per configurare i channels da seguire. Per essere stabile e' stabile, e l'API pur essendo limitata permette di fare qualsiasi cosa, alla faccia di QtGraphicsView che ad ogni minor release cambia comportamento ed ha una interfaccia troppo complessa per essere fruibile rapidamente.
Come supponevo il paradigma che sta dietro a codesto strumento va un attimo compreso prima di essere utilizzato efficacemente: all'inizio si puo' restare spiazzati dinnanzi alla totale assenza di widgets complessi che implementino le varie modalita' di interazione con l'utente, ma una volta capacitatisi del fatto che qualsiasi cosa si disegni sullo schermo puo' essere spostato, ruotato, e fatto divenire un elemento che reagisce a degli eventi esterni, si comprende il segreto intrinseco del toolkit: permettere di fare di piu', con meno.
Potrei dilungarmi qui in merito ai rischi del non avere alcuna limitazione nella definizione della propria interfaccia, fatto che si presta ad essere preludio alla totale disgregazione della coerenza tra diverse applicazioni, ma per ora interrompo qui: ci sara' modo e maniera di tornare su questi argomenti quando il tutto sara' piu' radicalmente diffuso grazie all'apparente progressiva integrazione in GNOME, e ci si potra' basare su dati concreti anziche' su illazioni.
Maggiori news sulle mie avventure estive a seguire...

RDF = Rendiamo Difficile Fare

Ci sono giorni in cui mi ricordo perche' le tecnologie semantiche non mi convincono affatto. Oggi e' uno di essi.
Dal mio reclutamento tra le fila Nepomuk e' passato del tempo, ma sinora si e' prodotto poco: qualche altra discussione in lista Xesam, mi son migrato a mano i tickets dal vecchio tracker al nuovo, e poco altro. Evidentemente tutta la fretta imposta all'inizio non esisteva affatto, ma di questo ho gia' parlato.
Ieri son stato direttamente precettato per dire la mia in merito ad una questione che potrebbe portare ad una pesante revisione nella gestione delle mail in NMO, l'ontologia destinata al trattamento dei messaggi. I ragazzi di Tracker hanno avuto la bella pensata di riportare nella struttura semantica una mappatura 1:1 delle mail, suddividendole nei vari componenti MIME di cui sono assemblate, ed adesso che sono fuori specifica gli urge che tali correzioni vengano integrate in Nepomuk per essere compatibili con Strigi; in sostanza, hanno buttato all'aria la precedente struttura che manteneva un minimo di coerenza tra tutti i tipi di messaggi contemplati nell'ontologia.
Il bello e' che neppure gli posso dar torto, in quanto il fatto di mantenere l'informazione integra della mail cosi' com'e' non e' forse da considerare vitale ma comunque importante. Dunque, come si fa?
Cio' che si evince da questa vicenda (tutt'ora in corso: ci sara' da bestemmiare per trovare non solo una soluzione che mantenga uno straccio di coerenza ma che vada bene pure a sti' fenomeni che hanno implementato la loro propria soluzione senza chiedere niente a nessuno) e' che forse forse l'idea di "etichettare" ogni genere di contenuto nel minimo dettaglio permette certo di maneggiare con piu' rapidita' e disinvoltura il dato, ma presuppone comunque una conoscenza approfondita del dato stesso. Nello scenario di cui sopra, qualora si mantenga la struttura proposta, chiunque vorra' trattare una mail dovra' essere ben cosciente di cosa e' MIME, quali sono i metadati usati per tenere le informazioni rilevanti, ed ovviamente dovra' cambiare strategia nel momento in cui vorra' reperire un messaggio di altro tipo, ad esempio un SMS. Ed evitiamo di parlare del caso in cui vorra' far convergere questi due elementi...
Il problema intrinseco, almeno nel momento in cui tali strumenti si applicano al desktop, credo sia nella eterogeneita' dei contenuti che si dovrebbero rappresentare: i files son fatti tutti a modo loro, secondo formati propri, talvolta noti e talvolta chiusi, e la loro rappresentazione richiede troppo spesso o una mappatura completa del formato stesso o una perdita: totalmente inutile se si vogliono far collassare piu' cose secondo un criterio unificato.
Ce n'e' ancora di strada da fare per rendere usabile sta' baracca.

opengnomedesktop.org

Finalmente son riuscito a mettere online questa roba: opengnomedesktop.org e' disponibile per tutti coloro alla ricerca di qualche nuovo tema con cui personalizzare il proprio ambiente Gnome, e possono navigarne una ricca selezione (presa da gnome-look.org) valutandoli per mezzo di thumbnails simili, per non dire uguali, a quelle comunemente disponibili nel pannello "Appearance" del sistema. Allo stato attuale solo i temi GTK+2 e quelli per Metacity sono trattati, prossimamente potrei aggiungere anche quelli per il mouse, i fonts e le icone.
Quanto ora online e' da considerare a malapena un proof-of-concept, ampiamente suscettibile a prossime migliorie: il demone di sync con gnome-look.org va perfezionato per non limitarsi a fetchare gli ultimi contenuti ma per allinearsi con altri dettagli di quanto gia' assimilato, va implementata l'interfaccia Open Collaboration Service per permettere l'accesso programmatico alle risorse, devo trovare un modo furbo per eseguire la generazione delle preview (gia' che per problemi tecnici non posso eseguirla in batch direttamente sul server), va introdotto uno straccio di sistema di news per il sito... Insomma, non sono manco all'inizio.
Ma ho comunque immesso il progetto tra le proposte per il gia' piu' volte citato Social Desktop Contest, anche al fine di raccogliere un po' di feedback, ed un poco alla volta entro nell'ottica di presentare un giorno il pacchetto completo direttamente al team Gnome per l'inclusione nella piattaforma: la libreria Glib per l'accesso ai provider OCS ce l'ho, l'applicazione web che raccoglie i contenuti in modo coerente anche, mi manca un prototipo di client dedicato che ricalchi appunto il layout del pannello Appearance ma tratti il materiale online anziche' quello installato localmente e dovrei avere piu' o meno tutto.
Gia' da qualche tempo in Gnome si sente la necessita' di una piu' stretta integrazione col web, nella prossima release 2.28 saranno inclusi diversi componenti mirati in tal senso, e mi piacerebbe provare a cavalcare l'entusiasmo per spingere anche l'integrazione con OCS: sorvolando sul problema odierno dell'unicita' del fornitore (solo la rete OpenDesktop e' al momento erogatrice di risorse per mezzo del protocollo) considero tale strumento assai importante per coinvolgere con maggior profitto all'interno della community free persone che pur non sapendo nulla di programmazione possono dare il loro contributo, almeno in termini di materiale ludico con cui abbellire il desktop.
La strada per il dominio del mondo passa anche per qualche simpatica icona...

libopengdesktop

Come precedentemente annunciato negli ultimi giorni mi son messo ad implementare una piccola libreria che permette l'accesso ai servizi web compatibili Open Collaboration Services con un wrapper Glib, e dunque facilmente usabile in Gnome e XFCE. Sebbene certamente non ancora all'altezza di attica, ovvero l'implementazione per KDE, credo che libopengdesktop sia gia' usabile per piccoli applicativi senza pretese: mancano ancora le funzioni che permettono di comunicare con il server remoto in modalita' asincrona, indispensabili per l'utilizzo in una qualsiasi applicazione grafica che interagisca direttamente con l'utente, ma gia' il GTK+ Theme Thumbnailer menzionato nel precedente post sarebbe realizzabile senza eccessivo sforzo.
Per quanto questa faccenda del Social Desktop Contest in parte non mi torni, in quanto sembra abbastanza una bufala architettata a tavolino per l'interesse di pochi (e come al solito approfondiro' queste tematiche sull'altro mio blog), ha comunque stimolato i miei neuroni gia' peraltro eccitati dal bioritmo estivo, ed ora mi trovo con una quantita' di idee grandi e piccine che potrebbero essere presentate o comunque messe in opera per il puro gusto di far qualcosa di utile. Poiche' gia' so che non riusciro' mai a realizzarle tutte le condivido nella speranza che qualcun'altro si prenda carico di qualcuna di esse: se cio' dovesse succedere, lasciate un commento a questo pezzo cosi' evitiamo di lavorarci in due...

• una implementazione AGPLv3 della piattaforma Open Collaboration Services (per quanto incredibile lo stesso OpenDesktop, riferimento stesso della specifica, sembrerebbe costruito su una piattaforma web closed source... Andiam bene...). Questo di per se dovrebbe essere il progetto che andrebbe ad includere anche il GTK+ Theme Thumbnailer, ed il primo su cui mi mettero' a lavorare non appena avro' un poco di tempo
  
• un driver Gwibber per le funzionalita' di microblogging incluse nel formato
• un driver Evolution per gestire i messaggi privati tra gli utenti
• un'altro driver Evolution (o comunque un convertitore iCal) per importare nel calendar le informazioni relative agli eventi che vengono pubblicati
  
• una qualche forma di integrazione con GeoClue per la gestione ad alto livello delle informazioni geografiche (magari una estensione di libopengdesktop?)
• una applicazioncina Facebook che condivida su tale popoloso network le attivita' svolte su una piattaforma Open Desktop
  

C'e' sempre qualcosa di nuovo da sviluppare. Peccato manchino sempre gli sviluppatori...

Fuori Onda

Giacche' il web sembra in fermento per l'ultima trovata Google, inutile non volerne discutere anche su questo blog.
In poche parole: Wave e' un tool per far convergere diverse forse di discussione, tra cui instant messaging e commenti sui blogs, e di editing collaborativo. Sara' che gli esempi forniti nel corso della presentazione ufficiale del prodotto (di cui e' disponibile il video nella homepage del progetto) sono abbastanza banali ed ingenui, ma al contrario della maggior parte della blogosfera a me non pare nulla di particolarmente eccitante.
Per la carita', una API che permetta di gestire in modo complesso gli stream di discussioni e commenti e' piu' che benvenuta, e gia' pregusto il momento in cui la includero' in GASdotto per arricchire le possibilita' di interazione degli utenti, ma in fin dei conti di strumenti per l'editing collaborativo ne esistono gia' a quintalate (sia web che desktop), e neanche si contano i mezzi con cui due o piu' persone possono comunicare in modo piu' o meno sincrono.
Probabilmente l'aspetto piu' innovativo del prodotto sta nella formalizzazione di un protocollo per l'aggregazione di contenuti, che garantisce la possibilita' di implementazioni inedite e maggiori spazi per l'integrazione di servizi offerti da diversi providers (nonche' di applicativi di interfaccia magari un po' piu' usabili che non il client Wave proposto da Google stessa, che mi pare tutto fuorche' immediato e semplice da utilizzare), ma come sempre c'e' da vedere se davvero tale arnese verra' portato laddove ce ne sarebbe bisogno, ovvero social networks e piattaforme di (micro)blogging, oppure se ancora una volta le divergenze del libero mercato concorrenziale imporranno limiti alla radicazione della specifica.

Piu' in generale, il mio giudizio nei confronti di questo genere di strumenti di carattere "social" e' sempre abbastanza critico: bellissima la possibilita' di condividere commenti, informazioni, notizie ed opinioni, ma se alla fine tutto questo popo' di tecnologia viene usato per far divulgare le foto delle vacanze non si ottiene nulla di piu' che non la versione globalizzata e 2.0 della "serata a casa degli amici a vedere le diapositive della settimana al mare". Quel che mancano non sono i mezzi, ma i contenuti, o comunque un qualche criterio che faccia emergere i dati realmente utili per la conduzione dei processi di decision making.
Gia' mi sono altrove espresso favorevolmente nei confronti dei nuovi media e dei canali di comunicazione "peer2peer" offerti dalla moderna Internet, ma giunti a questo punto ci si aspetterebbe da un colosso come Google (o da chiunque altro con un forte potenziale innovativo) qualcosa di piu' che non un servizio di instant messaging potenziato.
Forse la salvezza arrivera' dal semantic web, ma i tempi sembrano tutt'altro che maturi. Forse la salvezza arrivera' da Lobotomy, o da Itsme, o da qualche altro progetto che porta l'aggregazione dell'informazione al centro del modello di interazione, ma l'attesa sembra essere tutt'altro che breve. E nel frattempo aumenta la mole di informazione da filtrare a mano, e troppo spesso succede di perdersi i pezzi per la strada.

Social Software

Nella 2020 FLOSS Roadmap, il documento (assolutamente non ufficiale, ma comunque fonte di ispirazione) che descrive i punti chiave in cui sviluppare e promuovere il software libero nei prossimi anni affinche' possa viralmente innestarsi sul panorama IT precedendo le controparti proprietarie (ed alla fine conquistare il mondo!!! Mhuahahaha!!!), uno spazietto e' dedicato al "Social Software".
Mettendo le mani avanti in merito al significato che tale buzzword dovrebbe avere, e che nella mia interpretazione differisce dalla definizione fornita da Wikipedia, il termine mi ispira un concetto che val la pena di esplorare ed implementare, o quantomeno di uniformare a partire dalle gia' esistenti sporadiche incarnazioni. Tale concetto e' quello di applicare una dimensione "social" (nell'accezione di "social networking") alla distribuzione del software, integrando servizi collaterali come il rating e l'aggiunta di commenti per ogni pacchetto installabile per mezzo del package manager, si' da arricchire quasi passivamente la documentazione relativa alle applicazioni accessibili dagli utenti.
L'idea e' tutt'altro che nuova, viene gia' marginalmente applicata in Ubuntu (che rappresenta la popolarita' delle applicazioni con delle stelline di merito) ed in Entropy (il package manager di Sabayon, progetto che ho modo di seguire abbastanza da vicino e che non nascondo abbia in buona parte influenzato la mia posizione sui temi qui trattati), ma trattandosi di applicazioni indipendenti, non compatibili e limitate risultano solo parzialmente utili ai fini dello sfruttamento intensivo dell'idea. Per questo motivo ho gia' provveduto a gettare il sasso nello stagno di PackageKit, progetto FreeDesktop che punta all'astrazione del package management sulle piu' disparate distribuzioni ed esporre questa funzionalita' in modo che sia programmaticamente raggiungibile anche da applicativi che non siano il package manager in senso stretto, ed attendo qualche commento in merito.
In un futuro il proposito potrebbe essere esteso anche a forme di contenuti "user generated" piu' significativi che non gli sterili commenti, come ad esempio una maggiore interazione in caso di errore dell'applicazione (e conseguente bug report) e l'avanzamento di idee e proposte per nuove features e migliorie: anche in questo caso esistono gia' parziali implementazioni dai singoli vendor (ad esempio Firefox provvede a presentare il dialog di bug reporting in caso di errore, mentre il team Ubuntu gestisce un suo proprio collettore di suggerimenti online), e provvedere una soluzione unica, riusabile e facilmente gestibile (per evitare gli ovvi doppioni che scaturirebbero da una adozione di massa del sistema, da individuare nel modo piu' automatico possibile) permetterebbe di incrementare notevolmente le possibilita' di produrre software di gran qualita'.
Il sofware libero siamo noi, dunque tanto vale fornire strumenti efficaci per lo svolgimento del proprio compito.

Un Futuro che Non C'e'

L'altro giorno mi e' passato sotto gli occhi un bellissimo filmato che, strano a dirsi, viene da Microsoft: esso rappresenta la "vision" dell'azienda per l'adozione massiccia di tecnologie oggi esistenti solo in forma prototipale e sperimentale, e piu' precisamente in previsione di cio' che gli utenti potrebbero avere a disposizione nel 2019. Superfici tattili di ogni tipo, interfacce completamente touch che mutano a seconda del dato presentato o del device su cui vengono impiegate, carta elettronica su cui viene proiettata l'informazione...
Certamente affascinante. Un ottimo cortometraggio di fantascienza.
Con cio' non voglio assolutamente dire che quanto espresso sia irrealistico ed infondato, anzi ho precisato fin dall'inizio che in fin dei conti questa non e' che una artistica raffigurazione di strumenti hardware e software gia' oggi esistenti ed in fase di piu' o meno avanzato sviluppo, ma tra il dire (non senza un pizzico di ingenuita', perdonata per le evidenti esigenze di copione) ed il fare vi e' il baratro dell'interpretazione dell'informazione.
Splendido sarebbe copiare una porzione di un grafico da un device all'altro semplicemente puntando e guardando attraverso l'apposito vetrino, ma per far cio' i tre componenti (mittente, destinazione, e chi trasporta il dato) devono comunicare nello stesso linguaggio, secondo lo stesso protocollo, scambiando bytes di cui conoscono il significato; impagabile sarebbe variare l'informazione numerica in un documento tabellare girando la manopolina virtuale proiettata sulla scrivania, ma per fare cio' chi proietta suddetta manopola e chi traduce il numero prodotto in barretta colorata devono condividere la nozione su come trattare l'input; meraviglioso sarebbe "esplodere" il disegno tecnico pigiando il ditino sulla scrivania su cui e' appoggiato il mazzo di chiavi, ma per far cio' la scrivania deve sapere cosa c'e' scritto nel suddetto schema ed in che modo i componenti rappresentati sono interagibili o meno.
Insomma: il semplice "pezzo di ferro", per quanto sofisticato, semi-trasparente, mobile e reattivo al tocco, non serve a nulla se chi lo gestisce non sa cosa fargli visualizzare, e come. Questo popo' di apparecchiature e' perfettamente inutile se non esiste una capillare ed universale adozione di standard aperti, che possano essere trattati in modo univoco all'interno dell'intera infrastruttura integrata. Che lo si voglia o no, finche' l'informazione e' tenuta prigioniera all'interno di files Office, o Photoshop, o AutoCAD, solo Office, Photoshop ed AutoCAD potranno accedervi. Non il vetrino da puntare, non la manopolina proiettata, non la scrivania.
E il problema non e' certo rimandabile al 2019, ma va affrontato subito, per il semplicissimo fatto che prima di arrivare allo scenario dipinto nel filmato in oggetto sara' necessaria una graduale migrazione dalle tecnologie odierne a quelle prossime venture: e' chiaro che coloro che inizieranno a commercializzare i singoli prodotti che compongono il puzzle dovranno avere la possibilita' in prima istanza di interagire in qualche modo con l'informazione esistente e farsi strada poco alla volta nella vita di tutti i giorni, sia essa quella casalinga o produttiva, ma fintantoche' tale informazione non e' accessibile e manipolabile all'interno di tali nuove interfacce le possibilita' di concretizzazione entro tempi umanamente accettabili sono estremamente scarse.
Dunque: se il video vi e' piaciuto, e non vedete l'ora di utilizzare quotidianamente strumenti di tal fatta, assicuratevi di lasciare campo aperto all'innovazione ed alla penetrazione di tali tecnologie. Pensateci due volte prima di bloccare la vostra informazione (o peggio ancora, l'informazione da condividere con altri) all'interno di files chiusi e non interoperabili.
Partecipate alla costruzione di un futuro che non c'e', ma con il buon senso di tutti potra' essere.

Divide et Impera

Oramai ho cosi' tanti e variegati impegni che finiscono col sovrapporsi l'un l'altro secondo i piu' arzigogolati percorsi, ma cio' ha il lato positivo che con un singolo task ottengo piu' risultati utili per contesti completamente diversi. E' questo il caso del modestissimo progettino (sarebbe meglio chiamarlo "giocattolo") che ho aperto l'altro giorno su BarberaWare: Mignon, un client per le webradio.
In un colpo solo ho ottenuto: un playground ove iniziare a pacioccare e a prender mano con Python, orribile ed ingestibile linguaggio che mi tocca apprendere per assolvere ad alcune richieste del mio nuovo prossimo lavoro; un programmino da eseguire prossimamente nel PC recentemente installato in cucina, e con cui ascoltare il giornale radio cenando pur senza dover portare a spasso il laptop come attualmente faccio; una prima implementazione sperimentale di un concetto che gia' riportai su questo blog, in merito alla netta divisione di funzionalita' ed interfaccia del software. Sorvolo qui sulle invettive all'indecente linguaggio sopra menzionato ed alle mie abitudini domestiche, mentre mi soffermo su qualche considerazione in merito all'ultimo punto (l'unico dei tre in-topic su questo blog), forse banale e non particolarmente ricca a causa della modestia della mia attuale esperienza ma che quantomeno riporto per conoscenza.
Sviluppare una applicazione ove funzionalita' e interfaccia sono distinte non e' complesso, quantomeno non piu' che non progettare e realizzare un qualsiasi altro software con un po' di criterio: l'unico elemento cui probabilmente occorre prestare particolare attenzione e' la quantita' e la frequenza degli scambi di informazione tra i due strati: avendo a che fare con un protocollo IPC (che sia DBus o una coda di messaggi poco importa, sempre un qualche tipo di syscall esplicito o implicito e' necessario) meno memoria si sposta e meglio e', e le risposte non possono essere ne' istantanee ne' in realtime come all'interno di un unico processo. Di contro, come ci si puo' bene immaginare la flessibilita' della piattaforma e' completa: al momento il mio modesto programmino dispone solo di una umile interfaccia a linea di comando, ma gia' sto progettando di realizzare quella grafica in QT (altra tecnologia che mi tocca apprendere per intraprendere il mio nuovo mestiere) e quella web senza intaccare minimamente il core dedito all'interrogazione dei vari servizi di directory dei canali radio e alla riproduzione audio.
In sostanza: il paradigma mi garba e mi sembra utilizzabile senza particolare sforzo.
Un colpo al cerchio ed uno alla botte, alla fine qualcosa riesco sempre a combinare...

Senza Volto

Inevitabili le mie scuse per la sempre maggior rarefazione dei post su questo blog, ma l'ultimo periodo e' stato sufficientemente delirante, sono temporaneamente senza connessione casalinga (causa assorbimento di Tin.it in Telecom e susseguente chiusura dei contratti ADSL), ed i prossimi mesi saranno ancora peggio. Numerose volte ho letto o sentito qualcosa che mi ha ispirato commenti che avrebbero dovuto essere riportati qui, ma il tempo di stendere un testo decoroso e' sempre quel che e'.
Veniamo al sodo, ovvero a qualche constatazione sulla disponibilita' di applicazioni grafiche open.
In capo a pochi mesi mi e' gia' arrivata da piu' fonti nella mia cerchia di conoscenze tecnologicamente consapevoli una stessa osservazione, che ho a mia volta per incidenza constatato lavorando su tutt'altro: il panorama opensource e' ricco, florido, traboccante di librerie e framework per fare qualunque cosa, ma... mancano applicativi utente che rendano accessibili tali funzionalita'.
Un esempio tratto dalla mia esperienza recente: un amico da poco con il pallino da radioamatore insiste affinche' implementi un certo strumentino (rigorosamente per Linux) per l'analisi dei segnali audio, qualcosa di abbastanza semplice per poter fare un ben specifico tipo di studio. Di per se' tale programma non dovrebbe far altro che prendere un file .wav, tirarne fuori una trasformata di Fourier, e trarre qualche conclusione in funzione della distanza di determinati picchi a determinate frequenze. Mi sono assai stupito di non trovare qualcosa di gia' pronto nell'apparentemente vasto insieme di software free dedicato appunto ai radioamatori: ci sono dozzine di applicativi che eseguono analisi assai spicce e sommarie, disegnano simpatici grafici di scarsa utilita' se non coreografica, ma ben poco che si avvicini a quanto sinora descritto. Eppure della Fast Fourier Trasformation, funzione matematica alla radice di un po' tutta la scienza dell'analisi audio, esistono numerose implementazioni (fra cui una in particolare e' stata ottimizzata e perfezionata in ogni modo possibile): perche' non vengono sfruttate in software completi ed usabili dall'utente finale?
Qualcuno potrebbe obiettare che il mio esempio tratti una ristretta nicchia di utenza e che l'interesse nell'impiegare risorse umane per realizzare quanto richiesto e' limitato, ma analoghe situazioni si trovano anche in settori di assai piu' ampio consumo: tanto per dirne un'altra, poco tempo addietro un ennesimo amico mi ha fatto notare l'assenza di un qualsivoglia banale programma che permetta di ricavare un video a partire da un insieme di immagini statiche (a mo' di slideshow, insomma), ed io stesso, che nel prossimo futuro dovro' confezionare una serie di filmati mettendo insieme appunto foto, testi e qualche breve spezzone, con ogni probabilita' mi trovero' nella condizione di dover implementare un programmello che faciliti l'aggregazione di slideshow multimediali con effetti decenti materializzati con Clutter e passi il tutto a gstreamer.
Come si giustifica un tale prodigarsi di strumenti software di basso livello, di librerie e frammenti di codice atti a ogni genere di trasformazione matematica (e, dunque, di qualsiasi altro genere), cui non si controbilancia l'esistenza di reali applicativi che portino cotanto popo' di scienza alla portata del mouse? Il quesito e' di difficile risoluzione: indubbiamente una delle motivazioni e' la lontananza che c'e' nella natura di chi ha realizzato suddetto codice di analisi (persone di non scarso intelletto, capaci di tradurre complessi algoritmi in istruzioni elementari per il computer ma di principi sin troppo pragmatici ed immediati) e di coloro che potrebbero trarne programmi ad uso desktop (di ampia sensibilita' estetica ma misurate conoscenze matematiche, e troppo spesso rivolti all'utenza di massa anziche' alle piccole esigenze mirate), che frammenta ulteriormente il gia' mai sufficientemente grande bacino di developers esistente, e poi guardando all'altra sponda (le piattaforme non "libere") vediamo come all'atto pratico certe radicate modalita' di sviluppo e distribuzione del software, fondate non sempre sul profitto economico ma certamente sulla chiusura del codice (dicesi: freeware), assorbano la maggior parte di programmatori al mondo, instancabili produttori di programmini e utilities ma ben lontani dalla consapevolezze necessaria per aderire ad una licenza free as in speech.
Purtroppo non esiste un metodo unico ed universale per riuscire ad invertire questa tendenza, se non lavorare per realizzare semplici utilities e stimolare altri a fare altrettanto affinche' la potenza del software free esistente non resti a disposizione di una infinitesimale parte delle persone.

Strappando la Rete

La notizia l'ho letta oggi pomeriggio, e mi ha talmente entusiasmato che la riporto qui: qualcuno ha sviluppato un binding DBus per Javascript. O meglio: una versione taroccata degli engine di Gecko e WebKit in grado di interpretare istruzioni Javascript destinate appunto all'interfaccia verso quello che si sta affermando come lo strumento di IPC standard sul desktop Linux (e non solo).
Il Browser DBus Bridge rappresenta non solo una grande innovazione, ma uno sforzo che oserei definire pionieristico nei confronti della piu' e piu' volte paventata integrazione del Web con il desktop casalingo: con poche righe di codice un sito potrebbe interagire con l'intero sistema operativo locale, non solo per mezzo della pagina visualizzata nel browser ma con tutto il set di altri applicativi utilizzati comunemente dall'utente. Importare ed esportare (o anche combinare) dati da e verso l'Internet non sarebbe piu' questione di usare programmi dedicati e limitati per una specifica area, ma diverrebbe piu' immediato che scaricare un file e salvarlo sul disco.
Con ogni probabilita' questa opera non godra' mai di capillare diffusione (troppo vincolanti le implicazioni sulla sicurezza e sulla privacy, per cui non e' tollerabile che un qualunque sito possa andare a ravanare informazioni che non gli competono, e troppo limitata la diffusione di Linux sul desktop per giustificare una massiccia adozione), ma a parer mio merita comunque una menzione d'onore per la sua semplicita' e la valenza di tecnologia potenzialmente "distruttiva".
Ad ogni modo mi son marcato la pagina al fine di meglio approfondire il tema e tentare (quando avro' tempo...) di lavorarci un pochino sopra, anche e soprattutto all'interno del Progetto Lobotomy.

Modulare by design

Come talvolta accade questo post viene pubblicato piu' come mio personale appunto, in quanto non viene menzionato nulla di particolarmente nuovo sull'universo Lobotomy: gia' piu' volte ho ribadito la volonta' di spezzettare lo strato funzionale dell'intero sistema in diversi componenti indipendenti tra loro e con cui comunicare (localmente sulla stessa macchina, ma anche remotamente) per mezzo di D-Bus, adesso un poco alla volta sarebbe il caso di fare qualcosa di concreto (tempo permettendo).
Giusto negli scorsi giorni ho esposto questa mia idea su Gnome-Look.org ma ho ottenuto scarso feedback, soprattutto perche' comprensibilmente l'adozione di codesta architettura implicherebbe la riscrittura dell'intero Gnome e delle relative applicazioni e giustamente non e' una ipotesi particolarmente allettante per chi gia' ci lavora da anni, ma in questa stessa settimana ho avuto due pragmatiche dimostrazioni di quanto cio' non solo avrebbe pieno senso di esistere ma e' anche quasi una necessita' nel mondo odierno, ove sempre di piu' sono i devices (computer, laptop o mobili) usati da ogni persona: una volta avrei voluto abbassare il volume del player mp3 in esecuzione sul mio desktop, essendo mollemente adagiato sul divano col portatile sulle gambe ed avendo poca voglia di alzarmi, ed in un'altra occasione avrei voluto scaricare un file Torrent usando il mio server domestico (perennemente acceso, anche di notte) che pero' non ha un monitor attaccato ed e' accessibile solo via SSH. Chiunque potrebbe obiettare a queste mie osservazioni dicendo "bravo pistola, di applicativi che fan quello che vuoi ed usabili in remoto o via interfaccia web ce ne sono quanti ne vuoi, installati quelli e non rompere le scatole!", ma trovo questo genere di soluzioni assai povere e scarsamente flessibili: l'interfaccia sarebbe comunque sempre diversa tra un'applicativo e l'altro, e non v'e' modo di integrare la funzionalita' desiderata al di fuori del programma stesso.
Al momento sto valutando la possibilita' di iniziare a sviluppare uno straccio di client Torrent come dico io, dunque sottoforma di demone di sistema (costruito assemblando l'API gia' esistente) con cui dialogare in principio con un programmino a linea di comando e poi magari con un frontend grafico, ma sempre e comunque tenendo separate le componenti funzionali e quelle di interazione: se e quando mi decidero' a farlo chiaramente lo annuncero' qui e pubblichero' l'opera su BarberaWare, all'inizio lo svilupperei come applicativo a se' ed un giorno potrei riutilizzarlo all'interno di Lobotomy aggiungendo quelle due o tre funzioni per agganciarlo al resto del sistema.
Dopodiche' non sarebbe male esplorare la possibilita' di wrappare D-Bus in XML-RPC (con questo?) per eseguire comandi molto remotamente (non in LAN ma attraverso l'Internet, ad esempio per aggiungere un'altro file nella lista di torrents in download sul proprio server mentre ci si trova fuori casa, contesto in cui il solo D-Bus non se la cava troppo bene), costruire un sistema unico di discovery (con Avahi) e mettere insieme un framework facile facile per implementare interfacce web (un binding PHP di D-Bus ancora sembra non esserci, ma non e' che abbia particolare voglia di studiarmi pure Ruby...), insomma di spunti ce ne sono fin troppi.
Vedro' cosa riusciro' a combinare nelle due settimane di ferie dal lavoro che iniziano oggi...

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...

Modularizzare Kiazma?

Da qualche giorno galleggiava nella mia testa l'idea, e per coincidenza giusto pochi minuti fa' ho scoperto che forse la cosa si puo' fare senza particolare sforzo.
L'idea consiste nel permettere l'estendibilita' di Kiazma con moduli esterni: definendo a priori una interfaccia cui devono aderire i widgets rappresentanti ad esempio un result set sarebbe possibile implementare un proprio elemento grafico e piazzarlo in un plug-in, da linkare a runtime a Synapse ed usare quando direttamente menzionato da un viewer. In questo modo sarebbe facile ad esempio costruire un widget che rappresenti un result set come una struttura tridimensionale, o che evidenzi le relazioni di un certo tipo tra gli elementi coinvolti, o in forma di acquario in cui gli items galleggiano (e' solo un esempio, se qualcuno si azzarda a fare una porcata simile gli mozzo le gambe...), ed arricchire le applicazioni costruite per Lobotomy.
Ebbene: trovandomi per non so piu' quale ragione sul sito di GTK ho trovato un breve tutorial su come usare GTypeModule per gestire per l'appunto GTypes dinamici usando l'astrazione dei GModules (inclusa in Glib). Come parte integrante del documento viene fornito anche un simpatico esempio di cui devo ancora esplorare attentamente il codice, ma che in linea di massima sembra fatto apposta per venire incontro alla mia necessita'.
Devo ancora meditare sulle solite implicazioni "tecniche" che si aprirebbero offrendo questa possibilita' agli sviluppatori esterni (come gia' detto tante volte: meno liberta' viene garantita, piu' coerente e' il sistema nel suo complesso), ma e' una idea che andra' analizzata in futuro.

XML vs JSON

Nello scorso post ho fatto cenno alla possibilita' di non usare XML e XSLT per descrivere le applicazioni che dovranno essere (meglio usare il condizionale: "dovrebbero forse essere un giorno") integrate in Lobotomy, ma qualcos'altro.
Cosa?
Da un paio di versioni Clutter, quello che al momento e' il toolkit candidato per essere usato per l'implementazione della componente grafica del sistema, include una sorta di interprete JSON: dando in pasto ad un oggetto di tipo ClutterScriptable la descrizione di una scena formalizzata in tale linguaggio gli elementi vengono trattati e visualizzati, pure applicando effetti e cose graziose. Sembra proprio quel che ci vuole per l'"interprete" di programmi in Lobotomy ;-).
Il punto e' che la descrizione JSON e' statica, non prevede variabili come ad esempio il set di items estratti dal filesystem cui applicare l'effetto, ed urge trovare un compromesso tra la precedente proposta (result sets in XML e trasformazioni XSLT) con i nuovi orizzonti aperti da codesto strumento gia' bello che pronto.
La soluzione forse piu' ovvia e' quella di usare comunque XML e XSLT, ma per produrre un JSON da convogliare direttamente in Clutter ed ottenere l'elaborazione e la renderizzazione. Al momento mi sfugge come potra' essere possibile intervenire sulla "scena" astratta (e mascherata) dal ClutterScriptable per effettuare al volo i ritocchi dovuti a variazioni del result set rappresentato (la faccenda degli observers, gia' trattata), dunque esistono ancora margini di ripensamento e/o miglioramento.
Mi sa che alla fine l'interprete me lo devo scrivere da me...

Pipelines Grafiche

Leggendo questo articolo, e piu' in particolare il punto 7 della lista (che recita "Unless interface designers manage to offer the same functionality as the command line, that's not going to change -- and, frankly, not many are trying to do so."), mi torna in mente un vecchio proposito, diciamo "figlio" della gia' antica idea dell'OnMouseShell che si prevede per la componente applicativa di Lobotomy: riprodurre la funzionalita' della pipe (il carattere '|') caratteristica della shell Unix nell'interfaccia grafica.
Tutti sappiamo che la pipe nella linea di comando serve a usare l'output di un programma come input di un'altro, concatenando dunque piu' comandi in uno solo. Come interpretare questa funzione in un ambiente grafico, ove non esiste un output vero e proprio di un programma se non quello che viene disegnato nella sua finestra?
Per comprenderlo occorre fare un passo indietro, andando a ripescare il concetto per cui le applicazioni proprie del desktop environment Lobotomy non dovrebbero essere altro che trasformazioni di un result set estratto dal filesystem Hyppocampus; nel documento sopra linkato si parla di risultati in XML e programmi in XSLT, ultimamente sto un pochino rivalutando il formato da usare (e prossimamente esprimero' qui le mie elucubrazioni) ma la sostanza rimane la stessa. Se dunque riduciamo gli applicativi utente a manipolazioni di dati di formato universale e compatibili tra loro (o comunque artificiosamente resi compatibili), le cose si fanno un poco piu' strutturate: in questo contesto, la pipe dovrebbe permettere di presentare gli stessi dati in modalita' diverse, secondo schemi diversi, lasciandone invariate le proprieta'.
Facciamo il classico esempio chiarificatore: l'utente consulta la posta elettronica usando l'applicazione rivolta alla consultazione della posta elettronica (ovvero quella che dispone gli elementi a video con una lista di messaggi, lo spazio per la preview ed i pulsanti per comporre una nuova mail) cui viene passato l'insieme degli items presenti sul filesystem marcati come messaggi di posta. Poi pigia una shortcut (che potrebbe pure essere Win+Ctrl+\ , ovvero Win+| , cosi' si sfrutta pure quel che sarebbe altrimenti un tasto inutilizzato della tastiera...) e seleziona un'altra applicazione, ad esempio quella che funge da calendar, ed ecco che quegli stessi dati vengono presentati divisi per giorno di ricezione nella consueta griglia da calendar. Seleziona un singolo giorno, ovvero un sottoinsieme del gruppo di partenza (quello delle mail ricevute), di nuovo Win+| , seleziona il programma per l'instant messaging, ed ecco la buddy list delle persone che hanno inviato le mail di cui sopra.
Come concetto puo' forse apparire astruso, io stesso lo devo bene esplorare, ma una cosa e' evidente: in uno scenario del genere l'integrazione tra le diverse applicazioni sarebbe completa ed implementata ad un livello logico al di sotto delle singole applicazioni stesse (nel layer di trasformazione XML -> XSLT -> videata), e dunque implicita e trasparente.
Chi segue questo blog o ha comunque gia' letto qualche post puo' forse ricordare la precedente idea del plumb inverso: ebbene, questo qui illustrato ne sarebbe un utilizzo ideale (la trasformazione dalla lista di mail alla lista di persone da mettere nella buddy list nell'esempio sopra ne e' un dimostrazione), una funzionalita' basilare su cui le pipelines sarebbero costruite.
Un altro passo verso la convergenza tra la potenza della linea di comando e la semplicita' dell'interfaccia grafica...