Brand New World

Dovrei rispondere a un paio di email, ma visto che non ho mai avuto tempo/voglia di completare il post a tal proposito, direi di dargli la precedenza.

In più ora è ufficiale. Il nuovo sistema di Virtual File System di GNOME potrebbe atterrare tra sei mesi sui vostri affannati desktop.

Alexander "Capitano, oh mio capitano" Larsson ha appena richiesto di includere GIO e GVF tra i moduli proposti per la versione 2.22 di GNOME. Sì, lo so anche io che la 2.20 è ufficialmente uscita 5 giorni fa, ma che volete, i tempi dell'informatica sono questi. GNOME 2.20, che voi magari non avete neanche ancora provato, per altri è già superato.

Necessarie premesse

Come ogni report che si rispetti, è bene cominciare con calma, da principio e senza tralasciare nulla. Il che vuol dir che non posso dare per assunto che la differenza tra FS, VFS, GNOME-VFS sia nota, visto anche il casino che solitamente regna. Dunque:

• per FS (File System) si intende un metodo per memorizzare e organizzare file e i dati in essi contenuti. Nell'uso comune è FS sia il modello che l'implementazione (per esempio quando si parla del FS ext3, si può indicare sia la definizione astratta che l'implementazione fisica nell'hard disk che avete nel computer). Inoltre viene chiamato file system anche tutto ciò che risiede all'interno della directory radice nel proprio sistema - insomma, come casino iniziale non c'è affatto male
  
• per VFS (Virtual File System) si intende un livello di astrazione che permette di specificare una interfaccia tra un kernel e un file system ("reale"). Il virtual file system server per avere un solo metodo per compiere la stessa operazione (per esempio leggi) indipendentemente dal supporto su cui la si esegue (hard disk con GNU/Linux, hard disk con Windoze, CD-ROM, DVD...)
  
• lo gnome-vfs infine è anch'esso un livello di astrazione, che però non si pone tra il kernel e i dispositivi reali, ma tra l'userspace e l'applicazione di GNOME e che fornisce anche un certo numero di funzionalità non previste (e spesso del tutto estranee) al VFS, come ad esempio l'identificazione del tipo MIME e dell'applicazione che gestisce un certo tipo di file oppure l'accesso tipo-filesystem a cose che file system non sono oppure ancora la risoluzione di nomi di host.
  

Spero di aver chiarito come i tre layer si occupino di cose distinte. Oh, non dimenticate che lo gnome-vfs deve poter funzionare su kernel e sistemi operativi diversi, per cui è normale che vada a ridefinite alcune porzioni già presenti nel VFS.

Lo spettro del passato

L'attuale gnome-vfs ha sulle spalle 8 anni di utilizzo, rifinitura e migliorie. In realtà quello che spesso si nota di più sono le limitazioni e i problemi che presenta :-(

Proprio dal lungo elenco di questi problemi è partito Alexander Larsson ormai un anno fa:

• compatibilità assente - nell'ottica di interoperabilità tra i vari desktop environment, gnome-vfs è limitato al solo ambiente GNOME (senza scomodare altri sistemi operativi, KDE usa un proprio vfs praticamente incompatibile) e alle sole applicazioni che lo usano esplicitamente (notare che le applicazioni GTK-only non traggono alcun beneficio dalla presenza di gnome-vfs; un esempio dovrebbe essere la versione Linux di Acrobat Reader)
  
• supporto ai DisplayNames assente - non mi ricordo più che cavolo fosse, quando scrissi questa parte....
  
• supporto per le icone assente - già, sembra strano, ma essendo gnome-vfs svincolato per design da qualsivoglia toolkit grafico, al momento la scelta dell'icona da mostrare per un determinato tipo di file è demandata all'applicazione; questo comporta il non ottimale (e magari non esente da errori) ripetersi di codice per stabilire l'icona per un file nelle applicazioni.
  
• astrazione vincolata dal modello POSIX - sempre per design, gnome-vfs è stato progettato in modo da basarsi su un'astrazione simile a quella del modello POSIX (nel senso, credo di FHS, ma anche di read() e write()); tale astrazione ha mostrato nel corso del tempo i suoi limiti, primo tra tutti il seppur ottimo modello POSIX mal si presta a operazioni di alto livello sui "file documento utente" perché basato sulla distinzione dei file in file di configurazione, file di sistema, file di dati della applicazioni; il gnome-vfs invece opera per lo più su file che l'utente vuole aprire, leggere, spostare, copiare, insomma file che l'utente manipola direttamente nelle attività di tutti i giorni con un'astrazione a livello superiore. Allo stesso tempo basandosi sul modello POSIX, l'implementazione dei moduli dello gnome-vfs diventa problematica (esempio: seeking durante la scrittura su webdav, poichè webdav funziona in modo molto differente dal modello POSIX)
  
• framework di autenticazione - se avete mai avuto a che fare con i dialoghi di autenticazione quando tentate di accedere a una risorsa (remota) per la quale è necessaria una password, sapete quanto la cosa sia al momento arzigogolata.
• URI specifici di gnome-vfs - per identificare i file, gnome-vfs usa delle particolare stringhe dette "URI di gnome-vfs", per esempio file:///home/luca/file.txt. Oltre a seguire uno standard proprio (vedi problema #1), oltre ad avere una serie di problemi di escaping di tali stringhe (pensati ai nome di file con spazi e a come sono gestiti su diversi backend [fs reale, samba, webdav...] gestiti da gnome-vfs), l'aver definito URI queste entità ha spesso creato la falsa convinzione che gnome-vfs fosse progettato per gestire in toto gli URI di tipo web, con conseguente supporto ai link mailto: ed header http extra
  
• enorme numero di librerie esterne - gconf, ORBit, avahi, hal, dbus, popt, libxml, kerberos, openssl, libz, libresolv, fuse, samba, selinux... nel corso degli anni si è accumultato in gnome-vfs una serie di funzioni molto spesso non necessarie alle applicazioni, o meglio necessarie solo a poche applicazioni. Non si tratta di funzioni inutili, certo, ma di funzioni che andrebbero spostate altrove
  
• asincronicità delle operazioni - anche qui i problemi sono parecchi, primo tra i quali l'annullamento di una operazione asincrona
• varie ed eventuali - un esempio per tutti, vicino a quella che è l'esperienza giornaliera dell'uso di GNOME: un dialogo standard per l'avanzamento delle operazioni di copia/spostamento
  

Mi rendo conto che si tratta di un elenco di problemi più che altro tecnici e di design della libreria, lontani in fondo dall'uso quotidiano.

Se però non capite come mai non vi riesca di elencare tutte le risorse condivise via SAMBA o accedere a qualcuna di esse con GNOME, allora il problema è sicuramente in uno dei punti precedenti :-)

Nota: se in questa sezione avete letto qualche stronzata, è perché l'ho platealmente copiaincollata da un post mai pubblicato aggiornato l'ultima volta a dicembre 2006.

La luce alla fine del tunnel

Per la verità GIO e GVF erano disponibili già da qualche tempo in alcuni repository privati di Alex; da una settimana o lo sviluppo si era ufficialmente spostato sul repository SVN di GNOME. In simile data Alex aveva dato luce a un branch di sviluppo di Nautilus in cui gnome-vfs sarebbe stato sostituito da gio.

Con un messaggio in lista, fa il punto della situazione, dichiarando che forse è possibile includere GIO e GVF nella 2.22.

Di cosa si tratta esattamente? Dunque:

• gio - è una libreria basata su gobject che fornisce un'astrazione per diverse forme di Input/Output. In futuro dovrebbe essere inclusa direttamente in glib.
  
• gvfs - è una delle implimentazioni possibili di gio, in particolare quella che va a fornire il "vfs in userspace" simile a quello di gnome-vfs

Chiaro, no? No?!? Allora provo a tradurre un po' di più il messaggio di Alex

Astraimi il flusso

Dire in poche parole cosa è GIO non è facile, specie se voglio fare il divulgatore. Stando alle parole di Alex, al momento GIO include le seguenti funzionalità:

• Classi di base per gli stream di input e output - beh, se è un'API per consentire di effettuare l'I/O direi che una cosa del genere ci deve stare per forza, no?
• Implementazione concreta di alcuni stream - file locali, socket e buffer di memoria
• GFile - una astrazione di "filename", ossia un oggetto che rappresenta qualcosa simile a un percorso di nome di file, ma con in più la caratteristica di poter essere esteso in modo da rappresentare anche gli URI o qualcosa di completamente diverso (come dicevano i Monty Python). Nella pratica dovrebbe essere ciò a cui si appoggeranno le applicazioni per compiere le varie operazioni su file, ovunque essi si trovino
• Una implementazione di GFile per i file locali
• API varie per la gestione dei file, tra cui: annullamento di operazioni di I/O, tipi di contenuto (MIME?), icone, legame tipomime <-> applicazione che lo gestisce, monitoraggio di volumi, file e directory.

Ora, se voi siete sviluppatori e avete a che fare con problemi inerenti l'apertura, il salvataggio, lo spostamento o ogni altra azione che vi può venire in mente relative ai file, allora GIO è quella porzione del futuro GNOME Desktop in cui cercare la funzione che vi serve.

Notare come GIO sia un'astrazione, nel senso che, a parte l'ovvia implementazione relativa ai file locali, offre solo i metodi che gli sviluppatori andranno a invocare (o evocare), non i dettagli relativi ai singoli casi. Riprendendo l'esempio di Acrobat Reader, la Adobe potrà in futuro usare GIO (in particolare la porzione GFile) per le operazioni di apertura e salvataggio di file, l'utente di Reader potrà aprire o salvare file in locale o in remoto in funzione delle implementazioni presenti nel sistema in uso. Figo, no?

Ovviamente le singole implementazioni sono dei moduli, e con questo arriviamo a...

Implementami il virtuale

...GVF, ossia una implementazione di GIO che fornisce quel "vfs in userspace" simile all'attuale gnome-vfs.

Sempre traducendo l'email di Alex, attualmente le seguenti porzioni sono disponibili in gvfs:

• Una libreria client - un GModule che viene caricato da GIO e che implementa GFile e altra roba richiesta per consentire l'accesso e la manipolazione dei file. Tale libreria fa uso di DBUS per chiedere al demone (vedi punto successivo) in protocollo di I/O necessario
• Un demone gfvs principale - collegato alla sessione, tiene traccia di tutte le posizione montate e consente di montarne di nuove
• Un'orda di demoni di mount - ciascuna posizione montata è gestira da un demone separato (previene da instabilità reciproca dei vari demoni)
• FUSE - sì. come poteva mancare un supporto a FUSE? Ah, supporto a FUSE nel senso che le applicazioni che non fanno uso di GIO possono accedere via FUSE ai filesystem montati da GIO. Nel senso inverso... beh, scrivetevi un modulo!
  

La luce alla fine del tunnel

L'elenco (sterile, lo so) di caratteristiche forse non può dire molto. Allora metto su il berrettino da entusiasta[1] e dichiaro quanto segue.

GIO+GVFS non è la soluzione a spinosi problemi che affliggono l'intera umanità, cose come la fame nel mondo o il proliferare della armi da fuoco.

GIO+GVFS è una porzione del futuro GNOME Desktop e Piattaforma di sviluppo (quando GIO verrà incluso in glib) che, nelle intenzioni:

1. renderà più "snello" lo GNOME Desktop
2. renderà più facile per gli sviluppatori che scrivono codice per GNOME o anche solo per GTK+ produrre software che vada a mettere mano (o piede) su dei file (locali, remoti, astratti o altro che siano)
3. dovrebbe rendere meno problematico l'uso di file non locali e/o non reali agli utenti finali (anche se, ricordiamolo, l'utente principale di GIO è lo sviluppatore)
   

Tutto il resto è solo chiacchiere e distintivo.

Specie se le applicazioni che al momento usano per motivi diversi gnome-vfs per le operazioni su file non migrano a GIO+GVFS o se non si scrivono nuovi moduli :-)

[1] nella accezione che il noto psicologo/psichiatra/psiqualcosa Alberoni da nel suo bellissimo libro "L'ottimismo", ossia di quella persona che è al di là del pessimista e dell'ottimista, una sorta di imbonitore e trascinatore di folle umane...