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.
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é :
gaston 10275 1 0 11:17 ? 00:00:00 /usr/lib/gvfs-hal-volume-monitor
gaston 10588 10538 0 11:30 pts/0 00:00:00 /usr/lib/gvfsd
gaston 10616 1 0 11:31 pts/0 00:00:00 /usr/lib/gvfsd-trash --spawner :1.729 /org/gtk/gvfs/exec_spaw/0
gaston 10764 1 0 11:39 pts/0 00:00:00 /usr/lib/gvfsd-dav --spawner :1.729 /org/gtk/gvfs/exec_spaw/2
gaston 11335 29021 0 12:12 pts/8 00:00:00 /usr/lib/gvfs-fuse-daemon /home/gaston/.gvfs/ -d
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
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 
C'est clairement une avancée extraordinaire, mais que personne ne verra, et donc dont les développeurs n'auront que peu de crédit de la part des utilisateurs.
En revanche, ça risque vraiment d'apporter un grand confort aux développeurs d'applications, et donc d'être la base pour le développent d'applications qui elles seront visibles des utilisateurs.
Un espèce de héros de l'ombre quoi...
@bochecha Yep, c'est aussi pour cela que je suis aller remercier le développeur de gvfs-dav sur la mailling-list de GVFS. Et il a semble-t-il apprécier, ce qui confirme ton sentiment de peu de crédits. C'est aussi pour cela que j'en parle car comme tu le dis, l'avancée est extraordinaire mais les effectifs sont faibles. Si les utilisateurs peuvent comprendre et avoir le moyen de remonter des anomalies consolidées, cela ira encore plus vite.
Très belle explication concernant GIO/GVFS, j'essaye bien de suivre les évolutions entre versions du noyau Linux mais il y en a tellement...
@bochecha : Les développeurs en général agissent souvent dans l'ombre, malheureusement ou heureusement, je pense que la reconnaissance envers ces personnes vient avec les années à côtoyer leurs créations et l'intérêt que l'utilisateur va y apporter jusqu'à "découvrir" ce qui se cache derrière et je pense que n'importe qui ne peut être qu'admiratif face à "ces héros de l'ombre"
@StandarT merci
J'ai rajouté un schéma qui permet d'avoir une vue d'ensemble du système même si je ne le trouve pas très clair sur l'aspect FUSE (j'espère que le texte l'est plus).
Ce coup-ci, je vais pas te dire "Super billet, merci pour ces infos" mais plutôt quelques remarques plus ou moins utiles
J'aurais mis un petit lien vers la Roadmap de Gnome 2.24
Quels donc le thème GTK et le metacity que tu as sur la capture d'écran?
Joli icône de Gnome:)
Bon j'avais prévenu, mais quand même :
Super billet, merci pour ces infos
@Osku
J'ai rajouté le roadmap, bonne idée ! Surtout qu'il est assez dense celui-là.
GTK: clearlook-Olive
Metacity: KO3, de loin mon préféré avec le compositeur de metacity d'activé.
Icônes: Buuf Deuce (sur le site, et sur mon bureau
Pour l'icône du Gnome, il a l'air d'avoir pris un sérieux coup derrière la tête, ça me plaît bien
Comme d'habitude un bon billet très explicatif. Etant pro-kde je me demandais en quoi l'approche de gnome était mieux que celle de kde puisque d'après ce que j'ai compris une application non gnome sera tout aussi bloquée avec GVFS qu'une application Gnome avec les KIO_Slaves. Merci d'éclairer ma lanterne.
@zorglube alors mon billet n'est pas si explicatifs que cela mais à ma décharge c'est assez sioux
Tout l'astuce se trouve dans le démon gfvs-fuse-daemon. Comme tu le sais peut-être FUSE, est une API permettant de développer des systèmes de fichiers montable par l'utilisateur. On peut par exemple avec un programme en python, utiliser FUSE pour ajouter un nouveau système de fichier totalement virtuel, c'est à dire qui est complètement (arborescence des dossiers, fichiers, attributs, etc..) simulé par le dit programme python. Cette arborescence pourra ainsi être montée et apparaître pour toutes les applications sur le répertoire de montage, comme un des dossiers et fichiers normaux.
gvfs-fuse-daemon utilise ce principe en "virtualisant" les arborescences exposées par les démons monteurs et en les montant dans le dossier ~/.gvfs. Du coup les applications Gtk qui ont migrées vont utiliser l'API GIO pour directement parler aux démons-monteurs, et les autres applications passeront par le dossier ~/gvfs. Mais dans un cas comme dans l'autre, ce sont les démons-monteurs qui fournissent les données, il n'y a pas de copie en local de fichier. Après, pour les applications non-gtk, tout se passe par la boîte d'ouverture de fichier qui va, lorsque l'utilisateur ira sur un montage, substituer le bon sous-dossier de ~/gvfs. Pour les applications KDE, je ne sais pas s'il est prévu de patcher la boite d'ouverture de fichier ou de laisser l'utilisateur aller tout seul dans ~/gvfs.
Poster un nouveau commentaire