John Siracusa

Unification de l'API du système de fichiers

Mac OS X a dans le passé autorisé de nombreuses façons différentes pour se référer aux fichiers sur un disque à partir des applications. Les chemins classiques (du genre /Users/john/Documents/monFichier) sont supportés aux niveaux les plus élémentaires du système d'exploitation. Ils sont simples, prévisibles, mais ne constituent peut-être pas une idée géniale à utiliser comme seul moyen pour une application de suivre les fichiers. Voyez ce qui arrive, si une application ouvre un fichier basé sur son chemin, et que l'utilisateur déplace le fichier ailleurs pendant qu'il est encore en cours d'édition. Quand on demande à l'application de sauver le fichier, si elle n'a que le chemin pour le faire, elle va finir par créer un nouveau fichier à l'ancien emplacement, ce qui n'est certainement pas ce que voulait l'utilisateur.

Mac OS Classic avait une représentation interne des fichiers plus élaborée, qui lui permettait de retrouver des fichiers indépendemment de leur position réelle sur le disque. Cela se faisait avec l'aide d'identificateurs uniques de fichiers (ids), supportés par HFS/HFS +. L'incarnation Mac OS X de ce concept est le type de donnée FSRef.

Finalement, dans nos temps modernes, les URLs sont devenus le mode de représentation de facto pour des fichiers qui peuvent être localisé quelque part ailleurs que sur l'ordinateur local. Les URLs peuvent aussi se référer à des fichiers locaux, mais dans ce cas, ils ont tous les mêmes désavantages que les chemins de fichiers.

La diversité des types de données se reflète dans les APIs du système de fichiers de Mac OS X. Certaines fonctions prennent les chemins comme arguments, d'autres utilisent des références opaques aux fichiers, et d'autres encore ne fonctionnent qu'avec des URLs. Les programmes qui utilisent ces APIs passent souvent une bonne partie de leur temps à convertir des références de fichiers d'une représentations à une autre.

La situation est similaire quand il s'agit de récupérer les informations au sujet des fichiers. Il y a une quantité énorme de fonctions de récupération des méta-données du système de fichiers, et pas une seule d'entre elles ne permet de tout faire. La récupération de toutes les informations disponibles sur un ficher nécessite le recours à plusieurs appels, et chacun d'eux peut attendre comme argument un type différent de référence au fichier.

Voici un exemple fourni par Apple à la WWDC. L'ouverture d'un seul fichier dans la version Léopard de l'application Aperçu provoque :
• 4 conversions de FSRef en chemin de fichier
• 10 conversions de chemin de ficher en FSRef
• 25 appels à getattrlist()
• 8 appels à stat()/lstat()
• 4 appels à open()/close()

Dans Léopard des neiges, Apple a créé un nouvel ensemble d'APIs de système de fichier, unifié et complet construit à partir d'un seul type de données : les URLs. Mais ce sont des "objets" URLs, c'est à dire les types opaques NSURL et CFURL avec des passerelles entre eux, qui ont été inspirés par tous les attributs désirables de FSRef.

Apple s'est appuyé sur ces types de données parce que leur nature opaque permet ce genre d'amélioration, et par ce qu'il y a un grand nombre d'APIs qui les utilisent. Les URLs sont aussi la meilleure assurance pour le futur parmi tous les choix possibles, avec la partie scheme qui fournit une flexibilité pratiquement illimitée pour de nouveaux types de données et ne nouveaux mécanismes d'accès. Les APIs du nouveau système de fichiers construites autour de ces types d'URL opaques supportent les caches, et la recherche anticipée des méta-données pour améliorer encore les performances.

Il y a aussi une nouvelle représentation des fichiers sur le disque appelée les Bookmarks (à ne pas confondre avec ceux des browsers) qui remplacent les alias de Mac OS Classic d'une manière plus adaptée au réseau. Les Bookmarks sont la façon la plus robuste pour créer une référence à un fichier à partir d'un autre fichier. Il est aussi possible de rattacher des méta-données arbitraires à chaque Bookmark. Par exemple, si une application veut garder une liste persistante de fichiers "favoris", plus quelque information spécifique à l'application, et qu'elle veut que ce soit résistant à tout mouvement des fichiers derrière son dos, les Bookmarks sont le meilleur outil pour le faire.

Je mentionne tout cela, non pas parce que je m'attends à ce que les APIs du système de fichier aient un gros intérêt pour des gens sans fascination particulière envers cette partie du système d'exploitation, mais parce que comme Core Text avant elles, c'est une indication de la réelle jeunesse de Mac OS X comme plateforme. Même après 7 révisions majeures, Mac OS X lutte encore pour se démarquer de l'ombre de ses trois ancêtres, NextSTP, Mac OS Classic, et BSD Unix. Ou peut-être, cela montre-t-il comment l'équipe Core OS d'Apple est amenée à remplacer sans aucun ménagement des APIs vieilles et encroûtées, par des versions plus modernes.

Il va s'écouler longtemps avant que les bénéfices de ces changements se diffusent (vers le bas ou vers le haut?) jusqu'aux utilisateurs sous la forme d'applications pour le Mac, écrites ou modifiées pour utiliser ces nouvelles APIs. La plupart des applications Mac bien écrites disposent déjà de ce comportement désirable. Par exemple, l'application TextEdit de Léopard est capable de détecter correctement quand un fichier sur lequel elle travaille a été déplacé.

Document retiré

TextEdit, un bon citoyen Mac OS X

Bien sûr, la condition essentielle est "bien écrites". La simplification des APIs du système de fichiers signifie que plus de développeurs seront désireux d'étendre leur effort, -maintenant grandement réduit- pour proposer ces comportements favorables aux utilisateurs. L'amélioration en performance qui l'accompagne n'est que la cerise sur le gâteau, mais une raison de plus pour que les développeurs modifient leurs applications existantes et fonctionnelles pour utiliser ces nouvelles APIs.