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

Les Méta-données revisitées




Cela fait un certain temps que je n'ai rien écrit sur les méta-données sous Mac OS X. D'abord, une rapide définition pour les nouveaux venus sur ce sujet.
• Exprimé simplement, les méta-données sont "des données au sujet des données"
• Les méta-données de fichiers sont des informations associées à un fichier, qui ne font pas logiquement partie de contenu réel du fichier (autrement dit, ses données), bien qu'elles puissent y être asssociées physiquement.
• Les méta-données du système de fichiers sont des méta-données stockées comme éléments des structures de données associées à chaque fichier. La date de modification d'un fichier est un exemple classique de méta-donnée du système de fichiers, mais historiquement, le Mac en a beaucoup plus : les codes de type et de créateur, les drapeaux du Finder, la position de l'icône, l'étiquette, etc...

Tous ces termes ont des différences subtiles, et ne sont généralement pas interchangeables. Je vais essayer de les utiliser avec beaucoup de précision dans cet article.

Je suis tellement passionné par ce monde des méta-données du système de fichiers que j'ai écrit un article entier à ce sujet pendant l'été 2001. Aux débuts du développement de Mac OS X, il était difficile de deviner les intentions d'Apple dans ce domaine. Les mécanismes des méta-données de fichier dans les versions développeurs et dans les premières livraisons publiques de Mac OS X ressemblaient plus au résultat de leur double héritage Apple/NeXT, qu'à la manifestation d'un plan cohérent.

Mais, même plusieurs mois avant le livraison de la Béta publique, j'avais déjà acquis quelques idées sur les intentions apparentes du navire amiral. En relisant ce que j'écrivais en Juin 2000, mon excitation était visible. A cette époque, les seules recommandations d'Apple sur ce sujet étaient "d'encourager fortement les développeurs à utiliser les extensions de fichiers comme moyen alternatif pour identifier le type des documents".

L'arrivée de la version 10.0 le 24 Mars 2001 fut un événement tellement significatif que le problème des méta-données fut éludé pour des sujets plus importants. "Est-ce que cette version va marcher ?", "Puis-je utiliser mes anciennes applications ?", "Pourquoi diable se préoccuper de performance ?".

Au moment où la version 10.1 fut livrée en Octobre 2001, la politique d'Apple était claire : la décision était simple : tous les fichiers créés par des applications Mac OS X devaient avoir une extension au nom de fichier. (Allez la musique). Mes pires craintes s'étaient réalisées et ma réaction, fut rapide et sans pitié.

Je ne m'arrêtai pas là. J'en vins à proposer officiellement une autre façon de procéder pour Apple. Je créai une pétition en ligne (non, ne riez pas) pour soutenir une proposition qui recueillit presque 10 000 signatures, et des commentaires d'une grande partie de la communauté Mac. Voici celui que je préfère :

Je suis confiant sur le fait que les gens chez Apple pourraient finalement reconnaître le rôle que des méta-données de base comme le type/créateur joue dans l'expérience de l'utilisateur de Mac. Quand je travaillais sur le Finder en 1982, et créai le type/créateur, la base de données du bureau, et le mécanisme des ressources, je voulais être sûr que l'utilisateur n'aurait presque jamais à s'occuper de quel type de fichier il s'agissait, comment il devrait être nommé, et quelle application était en mesure de l'éditer. En même temps, je ressentais que le Finder devait autoriser les utilisateurs à supplanter les préférences d'application du Finder, si c'était nécessaire ; si bien que le glisser-déposer sur une application fut proposé. Dans les années qui ont suivi, les concepteurs de logiciels chez Apple ont fait du beau travail en maintenant cette facilité d'utilisation avec le Finder, et File Exchange. Mettre en avant la solution du plus petit commun dénominateur est inapproprié pour une compagnie vouée à l'innovation ; Apple a besoin de prendre en compte le concept entier de méta-données pour informer l'utilisateur, et considérer le Type/créateur comme le début de quelque chose de plus puissant pour Mac OS X.

Bruce Horn, membre de l'équipe de développement originale du Macintosh, signature 252.

Je postai la proposition de méta-données sous la forme d'une bogue par la procédure officielle (2826368) dans le système de suivi des bogues d'Apple, et j'attendis ce que j'espérais être un changement de direction d'Apple, ou au moins, une reconnaissance du problème.

Au début de 2002, Apple embaucha Dominic Giampaolo, le créateur du système de fichiers Be. BFS était l'un des systèmes de fichiers les plus élaborés de son temps, avec le support de méta-données extensibles arbitrairement, et des requêtes de recherche en temps réel efficaces. Dominic a écrit un excellent bouquin sur BFS, et la conception d'un système de fichiers en général. Ce livre est épuisé maintenant, mais il est disponible en téléchargement gratuit. Même actuellement, les caractéristiques de BFS, et ses performances ne sont pas égalées par beaucoup de systèmes de fichiers utilisés communément.

L'arrivée de Dominic chez Apple fut considérée comme un signe. Cela n'est pas difficile d'intéresser des enthousiastes du Mac à des possibilités futures. Fondée ou pas, l'attente était forte.

En Août 2002, Mac OS X 10.2 Jaguar sortit, sans modifications significatives à la politique ou aux mécanismes de méta-données. Deux jours après la sortie de Jaguar, Apple mettait fin sur son système de suivi de bogues à ma proposition de méta-données, avec le message d'état suivant : "Fermé/ Se comporte correctement".

Cela mit complètement en sommeil tout le processus des méta-données de Mac OS X. L'espoir irrationnel en Giampaolo des prêcheurs de méta-données se ternit considérablement. Ayant dit tout ce que j'avais à dire sur le sujet, et ayant fait tout ce que je pouvais pour provoquer le changement chez Apple, j'ai aussi largement abandonné le sujet. Que pouvais-je faire d'autre ? Des critiques avaient été exprimées, un avis avait été donné, et un spécialiste des fichiers avait été embauché. Tout ce que nous pouvions faire était d'attendre.

Mac OS X 10.3 Panther arriva en Octobre 2003. Il ne contenait aucun changement significatif à la politique et aux mécanismes des méta-données (Avez-vous déjà vu ça ?). Alors, on a attendu encore.

L'année 2004 est arrivée sans la perspective d'une nouvelle version majeure avant le début de 2005. Tout un chacun, qui réussissait à s'intéresser encore au sujet, devait affronter une réalité morose : en dépit de tous les efforts et des attentes, la situation des méta-données de fichier n'avait pas vraiment changé depuis la version 10.1 en 2001.

Un nouvel espoir

En Mars 2004, Apple sortit tranquillement une mise à jour de sa note technique HFS Plus Volume Format (TN1150). Elle décrivait une nouvelle variante de HFS + appelée HFSX.

HFSX est une extension de HFS + pour permettre de nouvelles caractéristiques qui sont incompatibles avec HFS +. La seule caractéristique actuellement définie est des noms de fichiers sensibles à la casse.

HFS + sensible à la casse (utilisé dans une interface utilisateur comme Utilitaire de Disque) fut en réalité introduit dans Mac OS X 10.3 Panther, mais n'était disponible dans l'interface graphique que dans Mac OS X Serveur. Cette fois, le nouveau nom, et l'intention avouée de "permettre de nouvelles caractéristiques qui sont incompatibles avec HFS +" montrait qu'Apple avait l'intention de faire quelque chose en termes de technologie du système de fichiers.

Puis, il y eut la section intitulée ": "Futur support pour des fourches nommées" qui contenait ces idées stimulantes et nouvelles sur les méta-données du système de fichiers.

De nombreux produits ont mis en place des solutions spécifiques pour stocker les données associées au fichier et au répertoire. Mais comme comme celles-ci ne sont pas gérées par le système de fichiers, elles peuvent devenir inconsistantes avec la structure de fichier et de répertoire.

HFS Plus a un fichier attribut, un autre B-Tree qui peut être utilisé pour stocker une information additionnelle sur un fichier ou un répertoire. Comme cela fait partie du format de volume, cette information peut être conservée avec le fichier ou le répertoire quand ils sont déplacés ou renommés, et peut être effacée quand le fichier ou le répertoire est effacé.

Puis, les choses commencent à chauffer :

Le contenu des enregistrements du fichier d'attributs n'a pas encore été entièrement défini, mais le but est de fournir un nombre arbitraire de fourches, identifiées par un nom Unicode, pour tout fichier ou tout répertoire.

(Je souligne) Ils l'admettent enfin ! On savait depuis longtemps que HFS + pouvait techniquement supporter un nombre arbitraire de fourches, mais le langage, dans la note technique, a lentement évolué dans la manière d'envisager ces possibilités. Après la mise à jour HFSX, l'intention semblait très claire.

Néanmoins, d'autres flux de données (les "fourches" dans le jargon Mac), sont toujours apparus comme une implémentation très lourde d'une extension arbitraire de méta-données. Il y a une autre raison pour laquelle la capacité de HFS + à supporter de multiples fourches nommées n'a pas été beaucoup plus qu'une curiosité dans le passé. Quoique les modifications de la note technique aient ravivé quelque intérêt, les problèmes techniques semblaient rester.

Mais il y avait un petit morceau d'information intéressant dans la note technique. Bien qu'elle précisait que "le contenu des enregistrements du fichier d'attributs n'a pas encore été entièrement défini", il y avait assez de documentation pour avoir une idée de ce qui allait arriver.

Chaque enregistrement [d'un fichier d'attributs] commence avec un champ recordType qui décrit le type d'enregistrement de données d'attributs. Le champ recordType contient l'une des valeurs suivantes :
listing

Les valeurs ont la signification suivante :
kHFSPlusAttrInlineData réservé pour usage futur
kHFSPlusAttrForkData
Cet enregistrement est pour un attribut des données de la fourche. Vous pouvez utiliser le type HFSPlusAttrForkData pour interpréter les données
kHFSPlusAttrExtents
Cet enregistrement est une extension d'attribut. Vous pouvez utiliser le type kHFSPlusAttrExtents pour interpréter les données. Un enregistement du type kHFSPlusAttrExtents est en fait seulement une extension de dépassement pour l'enregistrement correspondant de type kHFSPlusAttrForkData.

(Je souligne à nouveau). Des attributs "inline". Maintenant, on allait quelque part. Alors que toute la fourche semblait sur-dimensionnée pour de petits morceaux de données, le mot "inline" semblait correctement pesé. La phrase "réservé pour usage futur" relançait les attentes sur les méta-données pour Tiger.

Il s'avère que ces attentes vont être satisfaites de manière très intéressante. A partir du milieu de 2004, Apple commença à dévoiler publiquement, et à mettre sur le marché quelques nouvelles caractéristiques associées aux méta-données prévues pour Tiger. Si vous êtes un utilisateur occasionnel du Mac, ou peut-être pas utilisateur de Mac du tout, vous avez le droit de penser que vous savez où cela mène. Réfléchissez à nouveau.