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