Toujours dans mes webDaveries, je me suis mis à regarder de plus près le support de MacOS pour ce protocole.
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 sous Mac OS fonctionne comme Gnome à l'ancienne mode, par un montage brutal via un pilote équivalent à DavFS2.
L'avantage de la méthode est que les applications n'ont pas à savoir qu'ils travaillent sur le réseau. Et l'inconvénient... c'est la même chose. Les applications et le système lui-même travaillant comme sur un file system local ne prend d'un pas en compte les spécificités du protocoles, mais pire l'utilise d'une manière totalement contre-productive. A noter qu'à ma connaissance, MacOS est juste le seul système d'exploitation, ou même bureau (au sens Gnome/KDE du terme), à encore utiliser une telle approche, même Windows Explorer sait qu'il travaille sur un système distant et sait s'y adapter.
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 :
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...
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...
- répondre
Chamac'h , le 1 October, 2008 - 18:01Ha la la, comme c'est terrible ! Quelle histoire !
- répondre
Ulhume, le 1 October, 2008 - 23:45@Chamac'h Si c'est ironique, ne va pas plus loin sur ce site alors, car tout ou presque est du même acabit ici.
- répondre
Gagarine , le 2 October, 2008 - 22:39C'est domage que apple ne fasse pas un poil attention à la charge sur un réseau. Leur protocole bonjour par exemple est horrible avec les broadcast à tout vas. Bon évidement "ça marche" mais par contre la bande passante "utile" en prend un coup.
- répondre
Ulhume, le 3 October, 2008 - 00:09@Gagarine c'est ce dont je me rends compte depuis que je teste cet OS (que je n'avais jamais touché avant). Je suis pas sur que cela m'amuserait beaucoup de faire l'admin système sur un parc hétérogène avec 50% de mac... Déjà dans une VM je vois ce qu'une machine peu générer...
Poster un nouveau commentaire