1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

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.