Toujours dans mes webDaveries, je me suis mis à regarder de plus près le support de MacOS pour ce protocole.
Simple montages au lieu d'une gestion spécifique
Le support WebDAV sous MacOS fait parti du projet opensource Darwin. En fait pour simplifier Darwin c'est MacOS sans Quartz, le moteur graphique. Quoi qu'il en soit, même maquillée derrière la belle interface, le WebDAV de Mac OS est un simple montage par le biais d'un pilote équivalent à DavFS2.
L'avantage de la méthode est que les applications n'ont pas besoin d'être modifiées pour travailler sur un disque réseau, elles fonctionnent sur ce qui n'est pour elles qu'un simple dossier local.
Maintenant l'inconvénient est que l'abstraction qui se place entre le pilote du système de fichier et l'application, est une chose assez rustique. Pour s'en convaincre il suffit d'aller jeter un oeil sur l'abstraction de Linux. Nous ne trouvons ici pas de notions de meta-information ou de transaction qui seraient bien utile à un pilote qui communique avec un disque aussi lent que peut l'être WEBDAV et son protocole texte/XML.
Du coup, beaucoup des opérations qui devraient être "bas niveaux", se retrouvent gérées au niveau applicatif. C'est pour cette raison qu'est apparu d'abord chez KDE avec KIO, puis Gnome avec GIO, une couche d'abstraction intermédiaire dont l'objectif est de fournir une interface plus complète aux applications, et de se doter de pilotes qui peuvent exploiter ces nouvelles fonctions pour optimiser les transactions en communiquant directement, sans passer par un VFS, avec les médias les plus lent, tout en parlant avec VFS lorsqu'il s'agit de système de fichier locaux. Et c'est cette couche intermédiaire qui semble faire cruellement défaut à MacOS comme nous allons le voir.
Écrire un simple fichier texte...
Du coup, côté serveur, c'est l'hallucination. Je rappelle qu'ici le système de fichier monté est totalement virtuel. Ce n'est qu'une vue sur la base de donnée des contenus Drupal. Et voilà ce qu'il reçoit pour une simple sauvegarde de fichier :
PROPFIND /webdav/ : OK
PROPFIND /webdav/nodes/ : OK
PROPFIND /webdav/nodes/Billet/ : OK
PROPFIND /webdav/nodes/Billet/Dossier test/ : OK
PROPFIND /webdav/nodes/Billet/Dossier test/content.html : OK
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/.270-244568949-7.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/.270-244568949-7.html : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/.dat010e.006 : 404 Not Found
PUT /webdav/nodes/Billet/Dossier test/.dat010e.006 : 403 Forbidden
PROPFIND /webdav/nodes/Billet/Dossier test/._.dat010e.006 : 404 Not Found
PROPFIND /webdav/nodes/Billet/._Dossier test : 404 Not Found
PROPFIND /webdav/nodes/Billet/Dossier test/._content.html : 404 Not Found
Sérieux, j'avoue que jusqu'ici je n'avais pas pris la pleine mesure de l'expression "pourquoi faire simple quant on peut faire compliqué"... Une exploration jusqu'à la racine pour écrire un simple fichier, ensuite 6 tentatives pour lire un fichier de métas-données inexistant suivit de deux tentatives de lecture d'un fichier au nom bien étrange.
Après on sent qu'il cherche à créer un fichier temporaire, sûrement pour détruire le fichier d'origine et renommer celui-là à sa place. Pourquoi faire ? Mystère... Ceci dit, j'avais eu ce problème avec gedit 2.23, "bug" réglé avec la 2.24. De toute façon, là encore échec, ce qui est logique car MacOS l'ignore mais ce n'est pas un "vrai" système de fichiers et il ne peut donc pas écrire où il le veut comme cela.
Encore trois tentative pour interroger les métas-données un peu ailleurs et le système lâche l'affaire... sans sauver le fichier... Au final, 18 requêtes lancées pour un résultat nul...
Prendre en charge MacOS ne va, je le sens, pas une partie de plaisir... Arriver à lui faire croire que toutes ces magouilles aboutissent correctement me semble pour le peu... compliqué. Et le pire dans cette histoire c'est qu'il fait la même chose en lecture (en réussissant tout de même), soit 12 requêtes faites sur le serveur pour seulement ouvrir le fichier avec textedit...
Conclusion
En conclusion, au delà d'une belle expérimentation de l'inconvénient des montages par rapport à la prise en charge au niveau des librairies applicatives des protocoles d'entrées-sorties, Mac OS est clairement catastrophique dans sa gestion des méta-données. J'ai beau avoir fouillé les options de montage je n'ai trouvé aucun support des displayname (davfs2 sait le faire lui) et MacOS en lui-même impose beaucoup trop de requêtes au serveur : 12 requêtes à 250ms la pièce, je vous laisse faire le calcul...
Peut-être que je me trompe, mais l'approche qui consiste à présenter les données à l'application de la même façon qu'elles soient locales ou distantes me semble plutôt bonne, voire même simple, propre et élégante (oui carrément). Elle me semble en tout cas coller à la philosophie UNIX, en présentant le plus de choses possibles sous la forme de fichiers dans une arborescence unique, et cette philosophie a fait ses preuves.
Selon-moi (et encore une fois je ne prétend pas avoir raison), les optimisations nécessaires lorsque l'on écrit dur du Webdav plutôt que sur du fs local peuvent très bien être réalisées par le système de fichiers plutôt que par l'application, ainsi le design de l'application est plus simple (elle ne se préoccupe pas de l'endroit où elle écrit, ne doit pas connaître le protocole Webdav), on évite la duplication de code...
Le système de fichier peut tout à fait mettre des opérations en cache ou effectuer d'autres types d'optimisations adaptées. Après tout, son rôle est de fournir une couche d'abstraction.
Sinon, le fait de chercher à créer un fichier temporaire, n'est-ce pas pour profiter de l'atomicité du rename afin d'éviter toute perte de données (comme ça si un fichier du même nom existait déjà et que l'écriture échoue les anciennes données ne sont pas perdues, car le rename échoue totalement ou réussit, mais ne fait pas le travail à moitié, contrairement au write) ?
Présenter les données de la même manière en "slow fs" ou en "fast fs" n'est pas déconnant en soi. Ce qui est déconnant en revanche c'est de remonter au niveau applicatif des choses qui devraient être gérées par le FS. Un exemple, les métadonnées. MacOS en fait un usage intensif, c'est en soit très bien, mais il devrait alors dialoguer avec un FS qui connaît la notion de metadonnées et qui ne lui en présente qu'une abstraction. Ce n'est qu'à ce moment là qu'un FS particulier implémentant cette interface abstraite saura faire "au mieux" en fonction de la surface sur laquelle il doit travailler.
Tu parles de l'atomicité du renommage, et là aussi tu as raison, mais une fois de plus, ce devrait être à la couche abstraite de gérer cela, pas à MacOS de truquer pour obtenir de manière hasardeuse ce résultat. Une peu comme pour une base de donnée, la couche d'abstraction devrait offrir la possibilité de "commencer un transaction", effectuer ses opérations, puis "terminer la transaction". Charge ensuite à l'implementation de faire cadrer cela au mieux avec sa surface de travail.
C'est exactement cela que GIO cherche à réaliser, et c'est aussi ce qui manque semble t-il à MacOS. En somme, ce n'est pas, et tu as raison, le fait de tout voir comme un FS qui est en cause, mais plutôt de considérer qu'un FS c'est juste : read/write/rename/delete. Ca au fond, c'est une vision "magnético-old-fashion" du FS, qui n'est donc pas très abstraite.
Après avoir lu ton commentaire, je dois avouer que ton point de vue ne m'apparait pas clairement. Soit j'ai pas compris le billet soit j'ai pas compris le commentaire mais j'ai l'impression que tu y dis le contraire...
Dans le billet j'avais l'impression que tu voulais que l'application soit "consciente" qu'elle écrit sur le réseau, dans ton commentaire j'ai l'impression du contraire.
Bref, une petite clarification ne ferait pas de mal, surtout que le sujet m'intéresse donc j'aimerais comprendre tes propos.
J'ai refais mon intro, dis moi si cela te semble plus clair ainsi. Maintenant je tente d'expliquer le phénomène, je ne suis pas, loin de là, un guru du VFS.
Effectivement, ça me parait plus clair comme ça.
Par contre, l'idée de GIO/KIO ne me semble pas être l'idéal, il vaudrait surement mieux faire évoluer la vfs pour y incorporer ces fonctionnalités (mais concernant Linux je crois qu'ils sont assez conservateurs sur ce sujet).
Moui, je pense exactement comme toi, et je me doute que cela ne va pas évoluer de si tôt côté Linux. Ce qui expliques l'apparition de gluttes de substitution dans le "userland".
Publier un nouveau commentaire