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

Analyse et potentiel de Spotlight




D'abord, et avant tout, Spotlight est une excellente implémentation d'un concept simple et efficace pour des recherches dans l'ensemble du système de fichiers. Il est très rapide, très bien adapté, et à jour en permanence autant que la technique le permet. Il est aussi bien meilleur sous tous rapports que la recherche dans le système de fichiers de Panther, à tel point qu'une comparaison n'est même pas justifiée.

Des comparaisons avec Launchbar et Quicksilver semblent inévitables, mais Spotlight est d'une toute autre nature. Ces deux applications tierces se limitent à des sous-ensembles du système de fichiers, alors que Spotlight est conçu pour être aussi large que possible.

Spotlight est aussi entièrement centré sur les fichiers, alors que Quicksilver, notamment s'intéresse à beaucoup d'autres sortes de choses (recherches web, recherches dans le dictionnaire, marque-pages, processus actifs), et peut faire beaucoup plus avec elles (déplacer, copier, renommer, effacer, activer, tuer, récupérer l'info, etc...). Je m'attends en fait à ce que Launchbar et Quicksilver en sortent renforcés, en utilisant les APIs Spotlight quand c'est possible (recherches sur l'ensemble du système de fichiers), tout en conservant leurs caractéristiques propres.

Je suis un peu déçu par l'implémentation des dossiers intelligents. Pendant qu'Apple faisait du ménage dans le noyau pour mettre en place Spotlight, n'aurait-elle pas pu aussi implanter les dossiers intelligents d'une façon plus transparente ? Représentez-vous cela.

Un dossier intelligent devrait être un répertoire normal qui est marqué de façon spéciale en utilisant des attributs étendus (dans l'espace de noms "system."), rendus invisibles tout comme les attributs étendus utilisés pour les ACLs. Une recherche effective de Spotlight pour un dossier intelligent devrait aussi être sauvée dans un attribut étendu. Le contenu du dossier intelligent devrait être créé à la volée en réponse à des appels d'entrée/sortie du système (opendir(), readdir() etc...) et devrait être un ensemble de liens matériels en lecture seule sur les fichiers.

De cette façon, les applications n'auraient pas besoin d'être mises à jour pour être au courant des dossiers intelligents. Ceux-ci fonctionneraient tout naturellement comme on peut l'attendre, même à partir d'une ligne de commande. Voilà une belle chose.

Apple n'a même pas fourni ce niveau de transparence pour les alias (une honte), mais Spotlight a quand même prouvé sa capacité à jouer avec le noyau au bénéfice d'une bien meilleure expérience des utilisateurs. Je pense que ce serait une extension toute naturelle de ce système plein d'intérêt, que d'implanter les dossiers intelligents comme je l'ai décrit.

En ayant consacré plusieurs pages sur les méta-données du système de fichiers sous Tiger, avant même de mentionner Spotlight, j'ai essayé de prouver une chose. Et cette chose, c'est que Spotlight est un service de recherche et d'indexation un très bon service, rappelez-vous, mais rien de plus que cela. Il n'a pratiquement rien à voir avec un système de fichiers à méta-données arbitrairement extensibles, tel qu'il a été présenté, débattu et soutenu au cours du développement de Mac OS X, et implanté dans des systèmes d'exploitation comme BeOS, et des systèmes de fichiers comme BFS.

Oui, Spotlight extrait, stocke et indexe de l'information sur les objets du système de fichiers. Oui, cette information constitue des méta-données de fichiers. Mais cette information est extraite du contenu des fichiers, et des champs traditionnels de méta-données du système de fichiers (noms de fichiers, dates, tailles, etc...) et est stockée dans des indexes externes sous forme de fichiers normaux.

La seule façon réelle avec laquelle les méta-données arbitrairement extensibles du système de fichiers sont impliquées est quand une application décide d'écrire des attributs étendus quand elle sauve un fichier, et qu'alors, le greffon d'importation des méta-données de Spotlight lit ces attributs étendus, et passe leur valeur à Spotlight pour qu'il les stocke dans ses fichiers d'index. Au moment de la sortie de Tiger, aucune application existante ou greffon d'importation ne sait faire cela.

Spotlight se contente d'extraire, de stocker, et d'indexer les méta-données des fichiers. Il ne sait pas faire, et ne peut pas être utilisé pour rajouter des méta-données arbitraires à des fichiers. Il peut lire un fichier, et rajouter des méta-données dans l'index de Spotlight pour le compte du fichier, mais les méta-données ne sont pas "physiquement" rattachées au fichier lui-même.

Pourquoi est-ce que tout cela est important ? Pour y répondre il faut commencer par comprendre ce qui a motivé l'utilisation des méta-données extensibles dans Mac OS X.

La possibilité d'associer n'importe quel élément d'information à n'importe quel objet du système de fichiers fournit un nombre illimité de nouvelles façons d'organiser les fichiers. L'organisation "par défaut" repose sur le nom de fichier et sur son chemin - deux éléments de méta-données qui sont considérés comme si évidents, qu'on ne les perçoit même pas la plupart du temps comme des méta-données. Dans l'esprit de la plupart des utilisateurs, il y a simplement une hiérarchie de fichiers. En réalité, (et en particulier dans des systèmes de fichiers comme HFS+), le chemin et le nom de fichier ne sont que deux morceaux supplémentaires de méta-données, auxquels il arrive d'être traîtés spécialement dans certaine circonstances.

La promesse de méta-données arbitrairement extensibles, est que des nouvelles structures peuvent être définies par l'utilisateur en rajoutant des méta-données. Imaginez que vous marquez certains fichiers comme faisant partie du "projet Brinkman", ou comme "Urgent" ou comme "à venir". Maintenant, imaginez-vous créer des séries de dossiers intelligents contenant "tous les fichier Brinkman à venir", "tous les clips vidéo urgents créés ce mois-ci".

Vous pouvez croire que Spotlight est capable de faire ceci, mais Spotlight est limité pas les méta-données qui peuvent être extraites par les greffons d'importation attachés à chaque format de fichier. Microsoft Word peut avoir un champ de méta-données "Projet" dans son format de fichiers, mais de simples fichiers texte n'en ont pas, à coup sûr. Si vous voulez marquer un ensemble de fichiers hétérogènes comme appartenant à un projet unique, votre seule possibilité est la hiérarchie des fichiers (tout mettre dans le même dossier).

Cela vaut pour toute autre forme de méta-donnée, dont l'existence n'est pas garantie dans tous les formats de fichiers (et peut-être dans aucun d'eux) : l'urgence, la date de livraison, le sujet, le client, etc... Si vous voulez organiser des fichiers à partir de ces attributs, Spotlight ne va pas vous aider beaucoup.

Ce dont on a besoin, pour s'affranchir réellement de la hiérarchie du système de fichiers, c'est une façon pour l'utilisateur - pas pour les applications, pas pour les formats de fichiers, mais pour les utilisateurs - d'être capable de définir et d'appliquer n'importe quelle méta-donnée sur n'importe quel fichier. Les APIs d'attributs étendus de Tiger permettent de le faire, mais elles ne sont pour le moment pas reliées au système.

Pour envisager comment cela pourrait être dans le futur, considérez ce scénario :

• Un utilisateur, Jean, crée une image dans Photoshop. Quand Photoshop sauve le fichier, il précise que le fichier utilise des attributs étendus : le nombre de couches, l'espace de couleurs, la résolution, etc... Dans les cas où cela correspond à une clé d'attributs définie par Apple, (par exemple kMDItemPixelWidth), elle est utilisée. Sinon, des clés qui commencent par com_adobe_photoshop_ sont utilisées.

• Spotlight étant associé au noyau détecte la création de ce fichier, et déclenche non pas un greffon d'importation de méta-données, mais deux. Le premier est le greffon d'importation générique qui fonctionne sur tous les fichiers. Il lit toutes les méta-données standard du système de fichiers, (nom de fichier, dates, taille, etc...), plus tous les attributs étendus du fichier. Toute cette information est ajoutée à l'index de Spotlight.

Le second greffon est celui associé aux fichiers de Photoshop. Il connaît le format de fichiers de Photoshop, et il extrait toute information qui peut être déduite du contenu du fichier lui-même. Dans l'idéal, il n'y a rien à faire pour ce greffon d'importation, puisqu'une application bien conçue doit écrire toute information intéressante dans les attributs étendus du fichier quand elle le sauve. Mais des greffons spécifiques sont encore nécessaires pour des applications qui n'ont pas encore été mises à jour pour se comporter correctement.

• Jean répète ce processus pour plusieurs fichiers de différents types. A chaque fois qu'un fichier est créé, l'application rajoute toutes les méta-données dignes d'intérêt en utilisant les attributs étendus, et Spotlight extrait et indexe ces méta-données.

• Tous ces fichiers font partie du projet Brinkman. Pour l'indiquer, Jean les sélectionne toutes dans le Finder, et leur associe un nouvel élément de méta-donnée ("Project:Binkman"). Si l'attribut "Project"n'est pas déjà défini, Jean le rajoute, pour qu'il apparaisse dans le menu Pop-Up des attributs possibles dans le futur.

• Toujours vigilant au niveau du noyau, Spotlight détecte que ces fichiers ont été modifiés, et les ré-indexe consciencieusement en prenant en compte le nouvel attribut de méta-données "Project:Brinkman".

• Jean répète le processus autant que c'est nécessaire, en marquant les fichiers comme "à venir" ou "urgent"et en définissant des dates de sortie, ou des étapes de réalisation, comme "brouillon" ou "final", et ainsi de suite.

• Dans chaque fenêtre du Finder, Jean peut choisir d'afficher n'importe lequel de ces éléments de méta-données, en plus du nom de fichier, des dates, taille, etc... Chacun de ces attributs peut recevoir une couleur, le rouge signifiant "urgent", le brun "brouillon", et ainsi de suite.

• Finalement, Jean est maintenant libre de définir des fichiers intelligents comme ceux décrits précédemment : "tous les fichier Brinkman à venir", ou "tous les clips vidéo urgents créés ce mois-ci", ou "tous les brouillons d'image pour la Rand Corporation".

Voilà le futur tout puissant des méta-données que j'envisage, et pour lequel BeOS avait posé une option courageuse. Spotlight, et les attributs étendus amène Mac OS X très près, mais potentiellement seulement. Il n'est pas encore clair de savoir comment Apple s'est engagé dans ce concept des attributs étendus. Et je crois avoir montré maintenant, qu'ils représentent un élément fondamental de cette vison des choses.

Sous Tiger, HFS+ se contente de stocker les attributs étendus; Spotlight assure la construction et le maintien des indexes. L'un et l'autre sont attaché au noyau, si bien que l'effet est le même, mais il y a quelques différences significatives.

L'utilisation par BFS d'indexes de méta-données résidents dans le système de fichiers fournit une plus grande souplesse dans l'arrangement des données. Sous BFS, un petit fichier avec quelques éléments de méta-données pouvait être lu avec un seul accès de blocs continus sur le disque. Avec Tiger, l'utilisation d'index de fichiers externes pour stocker les méta-données extraites des structures internes des formats de fichiers fait que la tête de lecture doit visiter au moins trois endroits sur le disque : le fichier catalogue (pour récupérer les méta-données normales du système de fichiers comme le nom, les dates, la taille), le fichier lui-même (pour les données), et le fichier d'index de Spotlight (pour obtenir les autres méta-données).

Cet exemple néglige la mise en cache pour simplifier, et des implantations particulières peuvent varier pour chaque cas. Mais en général, à chaque fois que la tête de lecture doit se déplacer, cela conduit à une très, très mauvaise performance. L'approche "intégrée" qu'avait montré BFS est capable d'être beaucoup plus rapide et plus efficace.

Une seconde chose en faveur de l'approche de BFS est la fiabilité. C'est une évidence que le code des pilotes du système de fichiers est maintenu à un bien meilleur niveau que pratiquement tout autre code, y compris celui du noyau. Le code de certaines applications peut se permettre d'être plus lâche. Si une application se plante, c'est ennuyeux, mais une application peut toujours être relancée. Si le noyau se plante, alors, c'est plutôt mauvais, mais on peut toujours redémarrer.

Mais si le système de fichiers a une bogue, il peut potentiellement corrompre ou détruire toutes vos données. Aucune relance, aucun redémarrage ne permettra de corriger cela. Et, alors que des bogues dans une application ou le noyau peuvent corrompre et détruire des fichiers, une bogue dans un pilote du système de fichiers est beaucoup plus susceptible de le faire.

La conséquence, c'est que les pilotes du système de fichiers sont les morceaux de logiciels les plus fiables dans un système d'exploitation. Introduire un indexage de méta-données dans le système de fichiers lui-même garantit que ce code va être aussi fiable que le reste du code du pilote. Les utilisateurs ne peuvent tout simplement pas tolérer des bogues dans les pilotes du système de fichiers, point. Il suffit d'observer les tests de torture que BFS a enduré pendant le développement pour voir à quel point les contraintes de fiabilité sur le pilote du système de fichiers peuvent améliorer un morceau de code.

Finalement, il est souhaitable que le code soit dans le pilote du système de fichioers, et que les indexes soient intégrés au système de fichiers lui-même. Cela élimine le besoin de deux services qui doivent se synchroniser l'un l'autre dans le noyau (autrement dit, le pilote de HFS+ et le code d'importation des méta-données de Spotlight).

Cela dit, il y a aussi quelques avantages à l'approche utilisée par Tiger. Alors que le système utilisé dans BeOS ne fonctionnait qu'avec BFS, les index de Spotlight (des fichiers normaux) peuvent être créés n'importe où. Les APIs d'attributs étendus de Tiger se comportent aussi avec élégance sur les systèmes de fichiers incapables de les reconnaître. (En fait, je ne sais pas de quelle "élégance" les fichiers Point-Souligné disposent, mais techniquement, ça marche). Et grâce à l'utilisation de ses indexes externes, l'approche de Spotlight a aussi la possibilité d'indexer des média en lecture seule (même si elle ne le fait pas dans la version 10.4.0).

J'aimerais dans le futur voir une approche hybride dans Mac OS X, avec des volumes Mac OS X "natifs" qui utiliseraient un format de volume à hautes performances, nouveau et moderne, créé par Apple, avec la possibilité de stocker et d'indexer des méta-données arbitraires dans le style BFS, plus l'approche de l'index externe pour des systèmes de fichiers moindres, des données en lecture seule, et autres. Ce serait le meilleur des deux mondes.

Voici encore quelque chose à rajouter à propos du flux de méta-données de Jean évoqué précédemment. Le premier point du scénario décrit le stockage de méta-données de Photoshop dans des attributs étendus en utilisant les clés définies par Apple comme kMDItemPixelWidth et des clés préfixées par com_adobe_photoshop_. J'ai essayé d'insister jusqu'à présent sur le fait que les attributs étendus et Spotlight, sont de vraies technologies orthogonales. Et me voilà encore en train de les mélanger, en créant des attributs étendus qui utilisent des constantes Spotlight pré-définies, et des noms d'attributs personnalisé de style DNS inversé.

Cette technologie croisée est rendue possible parce que, comme quelques lecteurs peuvent l'avoir déjà remarqué, les indexes de méta-données de Spotlight, et les attributs étendus partagent les mêmes conventions de noms. Je trouve très invraisemblable que ce puisse être une simple coïncidence.

Une chose remarquable à propos des scénarios décrits ci-dessus est qu'il n'y a rien dans les APIs publiques de Tiger qui interdise l'un ou l'autre. Peut-être suis-je un peu trop optimiste, compte tenu de l'histoire récente d'Apple dans ce domaine, dans la prévision et les attentes de mes scénarios imaginaires. Mais au moins, l'indice d'une API grandiose, c'est qu'elle n'empêche pas inutilement des initiatives futures.

Les APIs simples et droites pour Spotlight, et les attributs étendus de Tiger laissent beaucoup de portes ouvertes. Et bien que je sois déçu par l'implantation des fichiers intelligents, gardez à l'esprit que ce sont des APIs non publiques qui les gèrent. Les dossiers intelligents sont une incarnation unique du Finder que peu d'applications Apple ont été rendues aptes à comprendre. Si bien que la porte reste ouverte pour eux aussi.

(Malheureusement, les applications tierces peuvent, et vont apprendre à lire les fichiers de dossiers intelligents du type .savedSearch malgré l'absence de spécifications publiques sur eux. Tout changement sur l'implantation des dossiers intelligents que Apple entreprendra aura à tenir compte de l'inertie créée par l'implantation actuelle, qu'elle soit documentée ou pas).

Le menu de Spotlight, et les interfaces utilisateur "avancées" de recherche sont décidément étonnants, mais ils se distinguent quand on les compare à la tentative maladroite du Finder d'utiliser le service. Heureusement, il n'y a rien qui puisse empêcher un développeur indépendant de créer une meilleure interface pour Spotlight. Rappelez-vous, le Finder, et même l'interface utilisateur "native" de Spotlight (la barre de menu et la fenêtre de recherche) ne font rien de spécial. Elles utilisent les mêmes APIs publiques de Spotlight comme peut le faire n'importe quelle application.

C'est pourquoi je suis enthousiasmé par Spotlight tel qu'il existe dans Tiger, ses défauts, et le reste. J'ai peu d'espoir que le Finder se redresse et fonctionne correctement dans un avenir proche, mais je suis absolument sûr que beaucoup des applications que j'utilise tous les jours vont bientôt utiliser Spotlight de façon plus intéressante et plus utile. Finalement, l'interface publique minimaliste aux fonctionnalités de Spotlight conserve pour Apple des options à peu près illimitées en ce qui concerne les implantations futures. Je croise les doigts.