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'URL et s'il trouve en trouve un, va lancer le démon monteur correspondant (gvfsd-dav dans cet exemple) en lui transmetant l'URI. 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 alors renvoyer à GIO le numéro directe pour atteindre ce démon-monteur dans l'avenir. Ensuite Nautilus causer directement avec le greffon pour explorer la resource. Lorsque l'on cherchera à ouvrir un fichier de celle-ci, il transmettra à l'application son URI et celle-ci va pouvoir à son tour la retransmettre à GIO qu'elle lui permette de 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. Il va pour cela tout simplement monter avec FUSE la resource comme avant pour que tout le monde puisse en profiter. Attention, il n'est pas question d'utiliser un pilote pour cela comme nous l'aurions fait avec un sshfs ou un davfs. Ce démon utilise les API de FUSE pour simuler un système de fichier qui va converser avec notre démon-monteur. 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 est compatible GIO) simplement en démontant un partage GVFS sous Nautilus. De plus, comme en témoigne le -d dans la trace plus haut pour gvfs-fuse-daemon, il ne se lance pas chez moi tout seul, je l'ai démarré à la main. Enfin dans la théorie les applications non compatibles GIO devraient malgrès tout voir apparaître les partages dans leur boîte d'ouverture de fichier, pour l'instant je n'y suis pas arrivé.
Maintenant la 2.24 n'est pas encore là réellement, et le fait que je tape ce billet sous gedit et qu'en faisant CTRL-S il soit sauvé sur mon site web, prouve bien que si tout n'est pas parfait, cela marche déjà très bien. Et c'est en tout cas une immence 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 forcemment celle qui font gogoter 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