C'est avec un grand plaisir que nous avons pu interviewer cette semaine Alex Larsson, responsable de gnome-vfs et co-responsable de Nautilus, à propos de l'actualité de gnome-vfs et de ce qu'il nous réserve pour l'avenir.
Résumé GNOME : Tu as récemment annoncé avoir ajouté DNS-SD à Nautilus. Peux-tu nous expliquer ce que cela apporte aux utilisateurs de GNOME ? Est-ce que ça permet par exemple une meilleure interopérabilité entre GNOME et Mac OSX ?
Alex Larsson : Fondamentalement, DNS-SD est une méthode de détection de services en réseau. Songe à tous les services pour lesquels il faut de nos jours saisir des paramètres (numéro IP, numéro de port, nom d'hôte); avec DNS-SD tu peux obtenir une liste intelligible de ces services et simplement sélectionner ceux qui t'intéressent.
Mon travail a surtout été de faire en sorte que ce type de fonctionnalité soit accessible, sous forme de bibliothèques, à toute application. C'est par ailleurs le cas de l'emplacement «Réseau» de Nautilus qui identifie les serveurs WebDAV et FTP présentés à DNS-SD et qui crée des liens vers ces volumes les rendant ainsi facilement accessibles sur un réseau.
Imagine par exemple que tu es à une conférence et que tu as besoin de fichiers se trouvant sur le portable d'Havoc. Tout ce que tu as à faire c'est accéder au «Réseau», et cliquer sur l'icône «Fichiers en partage d'Havoc». Pour que tout fonctionne, il faut tout de même que le service de partage de fichiers d'Havoc se présente à DNS-SD. Peu de serveurs Linux le permettent à l'heure actuelle mais j'espère que ça changera assez vite (sur Mac OSX, c'est déjà courant). On pourrait ainsi assez facilement lancer un service de partage à travers une session GNOME que DNS-SD reconnaîtrait et qui permettrait de partager $HOME/Shared par l'intermédiaire de WebDAV. Une fois ta session ouverte, tout le monde pourrait facilement avoir accès à tes dossiers partagés.
Ce qu'il y a de bien avec DNS-SD c'est que c'est un système qui utilise l'infrastructure existante, DNS en l'occurrence, et qui fonctionne aussi bien sur un réseau isolé de petite taille que sur une infrastructure lourde et centralisée. En réseau local, DNS-SD se sert d'un type de DNS reposant sur le multicasting : en gros, tu fais une demande de service sur ton réseau local et chaque pourvoyeur du service correspondant répond avec l'information nécessaire. C'est le côté Zeroconf de DNS-SD : tu mets une imprimante en réseau et tu la retrouves sur la fenêtre de dialogue des imprimantes.
Ceci dit, à partir du même système, tu peux aussi aller rechercher des services sur un serveur DNS normal. DNS-SD se sert du nom de domaine d'une machine pour demander au serveur DNS une liste des services du domaine en question. Comme ces serveurs sont sous la responsabilité d'un administrateur de système, c'est un moyen simple de configurer à un seul endroit les services d'une organisation, intranet ou imprimantes en réseau. Le fait que DNS-SD puisse être utilisé à la fois en mode local et en mode global a son importance. A mon avis les développeurs vont adorer le mode local et vont vouloir intégrer DNS-SD à leurs applications. Ceci devrait permettre aux fonctionnalités non-locals de faire aussi leur apparition ce qui pourrait s'avérer très utile aux entreprises, aux universités ainsi qu'à d'autres institutions de grande taille.
Maintenant ce qu'il nous faut ce sont des applications qui se servent de DNS-SD. Je ne peux évidemment pas tout faire tout seul c'est donc aussi à vous de jouer. J'ai bien sûr quelques idées en tête:
RG : Apple a récemment sorti un SDK pour Rendezvous. Est-ce que ça peut aider les développeurs de GNOME ? Selon toi, de quelle manière les applications GNOME peuvent-elles utiliser ce type de technologie ?
AL : La sortie du SDK de Rendezvous n'est pas si récente que ça. Ce qu'Apple a annoncé c'est la sortie d'une nouvelle version. L'annonce originale a été faite il y a longtemps (http://www.eweek.com/article2/0,1759,558330,00.asp).
Apple utilise pour ce code source la licence APSL (Apple Public Souce License) version 2.0 qui, bien qu'étant considérée comme libre par la FSF, n'est pas compatible avec la licence GPL. Les applications GNOME étant généralement placées sous la protection de cette dernière, il est peu probable qu'elles puissent utiliser le code d'Apple.
Le projet « howl » se propose de produire une version de Rendezvous compatible avec Linux et utilisant une licence de type BSD. Une partie du code vient encore d'Apple mais le plan prévoit qu'elle soit remplacée à un moment ou à un autre. On peut déjà compiler « howl » en ne liant le code d'Apple qu'au processus du serveur mDNSResponder grâce à un patch que j'ai soumi. La librarie est ainsi compatible avec la GPL et peut être utilisée par une application GNOME.
RG : Y a-t-il d'autres nouveautés dans la version 2.8 de Nautilus ?
AL : Il n'y a pas vraiment d'autres nouveautés puisque l'on s'est surtout occupé de fignoler toutes les choses que l'on avait ajoutées lors de la sortie de 2.6. Je me suis mis aussi à améliorer et à stabiliser les différents moteurs de gnome-vfs.
CVS réserve cependant quelques petites surprises:
Si tout se passe bien, on devrait pouvoir remplacer l'ancien système des types MIME par le nouveau décrit à http://www.gnome.org/~jrb/files/mime/). J'aimerais beaucoup que l'on puisse y arriver parce qu'à mon avis c'est l'un des points faibles de Nautilus.
RG : Est-tu satisfait de l'état présent de Nautilus ? Est-ce que tu as des projects à long terme, pour 2.10 et plus; des idées ?
AL : C'est une question difficile. De manière générale, un développeur n'est jamais vraiment satisfait puisqu'il finit souvent par se concentrer sur ce qui ne marche pas. Au quotidien je passe mon temps à lire les rapports de bugs, de réclamations et autres problèmes. Je ne me rends quasiment pas compte de ce qui fonctionne bien.
Ceci dit, si l'on repense au Nautilus des versions 1.x, avec lesquelles j'ai commencé à travailler, il faut bien avouer que je suis satisfait du chemin parcouru. Les efforts réalisés en matière de performance ont porté leurs fruits et Nautilus n'est plus une structure informe servant à visualiser tout type de fichiers mais bien un gestionnaire de fichiers.
À long terme, je voudrais voir Nautilus s'intégrer complètement au bureau de manière à ce qu'il ne soit plus considéré comme une application en soi mais juste comme un moyen d'accéder aux fichiers. On en est déjà bien près. Ce que je veux, c'est que Nautilus soit bien stable, qu'il fasse ce que l'on attend de lui et qu'il n'ait plus beaucoup besoin de maintenance. Au fond, un gestionnaire de fichiers n'a pas à être particulièrement remarquable.
Il n'y a pas encore de plan bien déterminé pour 2.10 mais il se pourrait que l'on travaille à ajouter un système de collection du type eog ou gThumb pour qu'il s'intègre bien à Nautilus.
RG : Est-ce que tu travailles à d'autres choses sur GNOME ?
AL : Je n'ai pas vraiment d'autres projets intéressants pour l'instant. De toute façon, avec le gel des fonctionnalités en vigueur, il vaut mieux se concentrer sur la correction de bugs et sur la stabilisation plutôt que sur les nouveautés.
Un petit article sur les clients GNOME de messageries instantanées...
http://web.subpop.net/text/gnome/IM.html
Gnome Summary est préparé par : Sri Ramkrishna, Sayamindu Dasgupta, Jim Hodapp, et Andrew Coulam. Traduction française : Sébastien Biot
gnome-summary@gnome.org
Devenez membre des Friends of GNOME! http://www.gnome.org/friends/
