Avec l'arrivée prochaine de Gnome 2.24, va s'officialiser une petite petit révolution qui reste pourtant bien discrète, l'intégration définitive de GIO, du portage des applications majeurs vers cette API, et l'arrivée de GVFS.

Montage ou librairie

Lorsqu'il s'agit d'accéder aux ressources d'un système de fichier étranger, et encore plus distant, il n'existe au fond que deux stratégies. La première datant de l'UNIX ancestrale, consiste à utiliser un pilote noyau (ou du domaine utilisateur avec FUSE), pour décrypter l'intrus et le raccorder par montage à la racine du système. C'est l'approche utilisé par Apple dans MacOS/Darwin, par Gnome avec l'ancien "Se connecter à un serveur" de Nautilus, par Gnome encore par la suite et de manière plus transparente avec le couple GnomeVFS/FUSE. Cette option présente cependant deux inconvénients. Le premier est la lourdeur de la gestion en arrière plan des montage cachés avec plus ou moins d'élégance. A ce jeu, MacOS s'en tire beaucoup mieux que GnomeVFS.

L'autre problème est que dés que le système étranger est monté sur la racine, rien ne le distingue plus aux yeux des applications qui y accèdent. Seul le pilote utilisé par mount est alors capable d'optimiser les assauts de l'application qui croit son fichier local. Et comme ce pilote est très prés du noyau, les fonctions dont il disposent sont de trop bas niveau pour pouvoir gérer cela au mieux. Ainsi la copie d'un fichier qui peut être gérée directement par le serveur distant en quelques octets devient un long aller-retour inutile et coûteux en temps.

L'autre option adoptée par KDE depuis des lustres consiste à mettre à disposition des application une librairie, KIO, qui offre toute les fonctions souhaitées pour manipuler, ouvrir, sauver, en flux ou en bloc, et ce à partir d'une URI "anonyme". C'est KIO qui en fonction du protocole de l'URI (ex. sftp://mon_serveur/mon_fichier pour un serveur SFTP), va choisir un greffon adapté, un KIO_Slave, qui va prendre en charge le dialogue effectif avec le serveur. Cette proximité de l'application permet d'offrir une API riche offrant aux greffons une meilleur opportunité d'optimisations de performances.

Cependant cette tactique n'est pas, elle non plus, sans inconvénient. En effet, si ouvrir un fichier texte avec Kate sur un serveur FTP est aussi simple que s'il était en local, c'est un peu plus compliqué lorsqu'il s'agit de Gimp via konqueror. Là KIO est obligé par konqueror à recopier le fichier en local pour que Gimp puisse y accéder. Ainsi si le système crash entre les deux, on aura beau avoir sauvegardé, le serveur, lui, n'aura rien vu venir...

Le meilleur des deux mondes

le couple GIO/GVFS a été conçu pour cumuler les avantages du montage et de l'API spécialisée tout en en annulant les inconvénients.

GIO est une librairie de développement incluse dans Glib au même titre que gObject ou gThread. Elle est ainsi accessible de toute application Gtk+ et représente à ce titre l'exacte équivalence de l'API KIO.

Avec Gnome 2.24, lorsque l'on saisi une URI du type dav://mon_serveur/ dans Nautilus, ce dernier utiliser GIO pour lui demander d'effectuer un montage de cette ressource. GIO va alors aller causer avec un module exécutable, gvfs qui est connecté en permanence sur DBUS . DBUS pour ceux qui l'ignorent est devenu LE système de communication entre application de Linux comme peut l'être Corba, DCOP pour KDE ou encore RPC-COM/DCOM pour Windows. Grâce à ce bus, le module gvfs va pouvoir entrer en contact avec gvfsd, le démon GVFS qui s'il n'est pas lancé, le sera par DBUS.

gvfsd va alors analyser le protocole de l'URI et va lancer le démon-monteur correspondant (gvfsd-dav dans cet exemple). le démon-monteur va alors contacter le serveur distant, faire deux trois échanges de politesse, puis établir la connection. Lorsque c'est fait, gvfsd va renvoyer à GIO le "numéro directe" qui permettra d'atteindre rapidement ce démon-monteur dans l'avenir. Ensuite Nautilus va commencer à causer avec le greffon pour explorer la ressource. Lorsque l'on cherchera à ouvrir un fichier avec une application, Nautilus lui fournir son URI. L'application pourra donc à son tour passer par GIO/GVFS pour lire ses données.

A ce stade nous sommes dans une configuration très proche de KIO. Si nous faisons un ps -edaf | grep gvfs, nous constaterons que tous ces processus sont bien en activité :

En plus de gvfsd et de deux démons-monteurs (dont un pour la poubelle...), nous voyons le processus gvfs-hal-volume-monitor qui a pour but de faire une passerelle entre HAL détectant les nouveaux médias (clef usb par exemple) et gvfsd. De même nous avons un étrange gvfs-fuse-daemon...

Ce démon est là pour permettre aux applications POSIX non-gtk de pouvoir elles-aussi communiquer avec le partage distant en utilisant non pas GIO (vu qu'il faut que les applications aient été écrite pour) mais simplement FUSE.

A l'origine FUSE a été créé pour permettre à un développeur de fabriquer un système de fichier virtuel de manière très simple et sans nécessité d'écrire de pilote pour le noyau. Il est ainsi possible avec FUSE, d'écrire une arborescence fictive avec un simple langage de script. Cette arborescence peut ensuite entre montée comme n'importe quel autre. Il est par exemple possible avec FUSE d'imagine construire un greffon permettant d'explorer son courrier comme s'il s'agissait de fichiers dans Nautilus.

L'idée concernant GVFS est d'utiliser FUSE pour permettre de monter de manière complètement standard (avec un mount), ce que voit le démon-monteur. En somme cela va permettre de monter... un montage. Ainsi nous avons le meilleur des deux mondes, les applications GTK parlent avec le démon-monteur via GIO, les autres via FUSE, tout le monde est content.

De la théorie à la pratique

Pour l'instant, à l'instar de HAL ou de DBUS, les débuts de GVFS sont encore soumis à bugouilles et autres plantounettes. Dans la version que j'utilise en ce moment, je peux par exemple planter gedit ou openoffice 3 (qui maintenant utilise GIO) simplement en démontant un partage GVFS sous Nautilus. De plus gvfs-fuse-daemon ne se lance pas (chez moi) tout seul. J'ai donc du le lancer à la main (d'où l'option -d pour debuggage). Enfin dans la théorie les applications non compatibles GIO devraient malgré tout voir apparaître les partages dans leur boîte d'ouverture de fichier, c'est même tout l'intérêt de FUSE, mais pour l'instant je n'y suis pas arrivé.

Enfin, certain démons-monteurs marchent très bien (ex. ssh) mais d'autres on plus de mal (ex. webdav). Il est d'ailleurs au passage intéressant de savoir qu'il est possible d'obtenir des traces permettant de cerner un problème en lançant dans une console utilisateur un /usr/lib/gvfsd --replace. Il est aussi possible d'augmenter le niveau de traces, par exemple du démon webdav en faisant avant un export GVFS_HTTP_DEBUG=all (les valeurs possible sont all, body ou header).

Conclusion

Maintenant la 2.24 n'est pas encore là réellement et tout ceci peut encore changer rapidement. En tout cas, le fait que je tape ce billet sous gedit et qu'en faisant CTRL-S il soit publié sur mon site web sous Drupal, prouve bien que si tout n'est pas parfait, cela marche déjà très bien.

Quoi qu'il en soit, une chose est sure, il s'agit là d'une immense lacune de comblée par rapport au confort qu'offrait KDE par rapport à Gnome. Dans l'avenir j'imagine que de nombreux démons-monteurs vont naître prenant en charge les protocoles les plus exotiques comme Sieve ou encore Imap.

Comme quoi, les plus belles avancées ne sont pas forcement celle qui font gigoter le bureau en tout sens

Commentaires