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 types de fichiers revisités




La question du type de fichier est un sujet de discussion pour Mac OS X depuis que les extensions de noms de fichiers sont devenues obligatoires dans le guide de l'interface utilisateur d'Apple de 2001. Si on fait abstraction des problèmes philosophiques, il y a des difficultés réelles, pratiques avec les extensions de noms de fichiers comme moyen de stocker et d'identifier une information sur le type de fichier. Ignorons même complètement les problèmes de stockage, pour nous consacrer seulement à l'identification d'un type de fichier.

La première difficulté, avec les extensions de noms de fichier comme moyen d'identification du type de fichier, c'est qu'elles ne sont pas uniques. Les extensions sont utilisées par de nombreux systèmes d'exploitation, et il n'y a pas de règle universelle attribuant un type de fichier à une extension.

Peut-être que l'unicité "universelle" est un standard trop élevé. Mais même à l'intérieur d'un seul système d'exploitation, beaucoup de noms d'extension sont sur-employés. Même .doc que beaucoup de gens connaissent comme l'extension des documents Microsoft Word, est utilisé par au moins quatre autres applications : FrameMaker, WordStar, WordPerfect, et DisplayWrite. Il est clair qu'un type de fichier ne peut pas être identifié à coup sûr, et uniquement, à l'aide de son extension.

Ce problème à lui seul suffit à disqualifier les extensions de noms de fichiers comme étant un système d'identification de type "convenable" (et encore moins "bon"). Mais, même si on ignore cette déficience, il y a un autre inconvénient. Historiquement, les extensions de noms de fichiers ont été opaques ; l'extension entière est une seule chaîne avec aucune structure interne prédéfinie. Cela interdit tout système d'héritage ou d'espace de noms.

Apple s'est montrée plus expressive que la plupart des autres vendeurs avec ses extensions de fichiers. Les dossiers intelligents ont l'extension ".savedSearch" ; les ajouts de texte ont l'extension ".textClipping" ; les frameworks ont l'extension ".framework". Dans le monde Windows, ces extensions auraient probablement été quelque chose comme ".smf", ".txc" ou ".fwk" respectivement. (En dépit de la limite de trois caractères abandonnée depuis longtemps, des extensions, Microsoft continue à privilégier des extensions de noms de fichiers "compatibles", et par conséquent, les noms de fichiers eux-mêmes). De toute façon, les extensions restent imprécises, et rigides.

Il y a eu beaucoup d'autres systèmes de définition de type dans le passé. Mac OS Classic utilisait une combinaison de deux entiers de 32 bits, habituellement exprimés par des chaînes de quatre caractères pour identifier les types de fichiers. Apple tenait un registre des codes de type et de créateur. Comme aucune autre plate-forme ne les utilisait, c'était une garantie d'unicité parmi l'ensemble des applications Mac respectables. Mais les codes type et créateur sont encore moins expressifs que les extensions de noms de fichier, surtout les extensions verbeuses utilisées par Mac OS X. (La localisation intelligente des codes type et créateur compensait largement cela cependant).

Plus récemment, le système de définition de types MIME, conçu initialement pour l'utilisation du courriel, s'est répandu dans d'autres domaines, et particulièrement sur le web. Les types MIME sont des chaînes de texte hiérarchiques avec des règles bien définies pour contrôler leur format. Alors qu'une image JPEG peut avoir une extension ".jpg" ou ".jpeg", et dans Mac OS Classic un code type "JPEG", le type MIME serait "image/jpeg", qui indique que JPEG est un sous-type de "image". Il y a peu de types primaires officiels (image, video, audio, text, application, etc...) mais il y a plusieurs dispositions pour des extensions spécifiques à des vendeurs ("application/vnd.ms-excel") ou à des circonstance ("x-world/x-3dmf").

BeOS pionnier comme il l'était dans le domaine des méta-données, a décidé d'utiliser MIME comme mode natif de définition de type. C'était supérieur aux approches de Mac OS classique et de Windows, car elle stockait ses méta-données de type de fichier dans un endroit dédié et précis, comme Mac OS classique, mais aussi permettait une hiérarchie de types de fichiers et un mécanisme d'expansion.

BeOS n'a pas vécu assez longtemps pour en expérimenter les avantages et les inconvénients, mais MIME avait aussi ses faiblesses comme système de définition de type de fichiers. La hiérarchie MIME à deux niveaux était très insuffisante. Bien sûr, tous les types MIME image sont sous "image/...", mais rien sur le vendeur qui crée le nouveau format d'image ? Les nouveaux sous-types de "image/..." ou de n'importe quel autre type de niveau supérieur doivent être "enregistrés et approuvés par l'IANA" conformément à la RFC. La seule autre option possible est d'utiliser un préfixe "x-" qui n'offre aucune garantie d'unicité.

Maintenant, imaginez qu'un vendeur invente un nouveau type qu'on ne peut raisonnablement placer qu'au niveau supérieur. En fait, cela ne demande pas beaucoup d'imagination, parce qu'il y a des fichiers de formats existants, qui se trouvent déjà au delà des types de niveau supérieur de MIME; MIME définit des types pour la vidéo, l'audio, et les images, mais rien qui puisse englober une séquence QuickTime, qui contient dans le même fichier à la fois de la vidéo, de l'audio, et des images.

MIME offre bien le préfixe "x-" pour des types au niveau supérieur, mais rien ne garantit l'unicité. Il y a aussi le sous-type "application/vnd.*" tel qu'il est utilisé dans "application/vnd.ms-excel" par exemple. Mais même cela ne satisfait pas à l'unicité (Microsoft dispose de "vnd.ms-*" ; et alors ? est-ce que Apple peut utiliser "vnd.apple-*" ; et pourquoi pas "vnd.apple.*" ? Aucune certitude).

Finalement, tous ces compromis contournent la hiérarchie voulue de MIME. Tout ce qui est sous le préfixe "x-" ou caché dans "application/vnd.*" ne sera pas considéré comme un joker MIME à l'égal de "image/*" qui est sensé prendre en compte "toutes les images". Une telle correspondance négligera toutes les images spécifiques au vendeur, et les autres, qui ne font pas partie de la liste (officielle et limitée) des types d'images MIME reconnus par l'IANA.

Bon, alors, on vient juste d'éliminer les extensions de noms de fichiers, les codes type et créateur de Mac OS classique, et les types MIME comme types satisfaisants dans un système de définition de types de fichiers. Que peut faire un vendeur d'OS ?

Comme élément de sa contrition (que j'espère) sur les méta-données de fichiers, Apple a pris un nouveau départ pour la définition des types de fichiers sous Mac OS X. La situations sous Panther et les versions précédentes était plutôt sombre ; tous les systèmes de définition de type décrits ci-dessus étaient utilisés à un endroit ou à un autre. Mais si j'étais obligé de désigner une seule (officielle) définition de type, je dirais : les extensions de noms de fichiers.

Les extensions de noms ont été le seul mode de définition de type que toutes les applications d'OS X exigeaient d'utiliser (selon les règles de l'interface utilisateur d'Apple). Les applications pouvaient décider d'utiliser le type et le créateur, et beaucoup l'ont fait, au moins au début. A mesure que le temps passait, de moins en moins s'en sont souciées.

Les types MIME étaient associés à des extensions de noms de fichiers, et quelque fois à des codes type et créateur, par des applications qui avaient besoin d'utiliser des données encapsulées ou marquées MIME (comme Safari ou Mail). Mais sans le support des attributs étendus, il n'y avait pas de place pour stocker réellement les types MIMES dans les fichiers réels.

Il y avait des APIs pour gérer ces trois formes de types de fichiers. Malgré une standardisation de-facto sur les extensions, considérées comme le seul vrai (bien que pas fameux) mode de définition de type, dans Panther et dans les systèmes précédents, des APIs différentes réclamaient des arguments différents pour les types de fichiers. Particulièrement au début de Mac OS X, les APIs Carbon avaient tendance à utiliser les codes type et créateur, alors que les APIs Cocoa utilisaient les extensions de noms de fichiers. Au moment où Panther était sorti, la plupart des APIs avaient appris les trucs de leurs jumeaux.

Panther introduisit en fait un quatrième mode de définition de type, plus générique, pour utiliser avec les données du presse-papier (clipboard, rebaptisé pasteboard). Il y eut peu d'annonce, et encore moins de documentation. Seuls les développeurs qui avaient à utiliser les APIs, étaient susceptibles de s'en apercevoir, et pour eux, cela n'avait rien à voir avec le type de fichier.

Et bien, sous Tiger, cet étrange type de donnée système pasteboard s'est épanoui en quelque chose de plus important : le nouveau, vrai système de type de fichier de Mac OS X. Et à la différences des extensions de fichiers, il n'est pas handicapant. En réalité, il est supérieur à tous les systèmes de définition de type décrits précédemment. Enfin une solution qui s'harmonise avec "le système d'exploitation le plus avancé au monde".

Le nouveau système d'Apple utilise des "Identificateurs de Type Uniformes" (qui se confond malheureusement avec le sigle médical "UTI"), et voilà comment ça marche.

Les identificateurs de type Uniformes (UTI)

La première chose à comprendre, c'est que, selon Apple, "ils identifient de façon unique une classe d'entités considérée comme ayant un "type"". C'est une description à peu près aussi large que vous pouvez l'imaginer, mais en français, cela signifie que les UTIs décrivent beaucoup plus que des formats de fichiers. Ils peuvent aussi décrire des données (par exemple dans le presse-papier ou dans un flux), des groupes de fichiers structurés et des dossiers (par exemple les paquetages -bundles- de Mac OS X), des liens symboliques, des liens matériels, et même des volumes de disque entiers. C'est vraiment comme Apple le décrit : si cela existe dans le système comme une entité d'un type identifiable, c'est un candidat pour UTI.

Les UTIs sont là pour résoudre tous les problèmes d'extensions de noms de fichiers, de codes type et créateur, de type MIME.

L'unicité : comme nouveau système de définition de type de données, les UTIs ne sont pas entravés par les fautes passées. Ils sont définis comme uniques, et il y a un mécanisme pour s'assurer qu'ils le restent.

L' expressivité : les UTIs ne souffrent pas de restrictions de longueur, et sont associés à des descriptions qui sont compréhensibles (lisibles, et sur option localisables).

L'extensibilité : Les UTIs supportent un système bien défini pour rajouter de nouveaux types facilement et sûrement, avec l'accord de l'organisateur (ici Apple) ou sans cet accord.

La taxonomie : La sélection d'un sous-ensemble de type de données (par exemple "toutes les images"), est simple, et n'exclut pas les UTIs spécifiques (à un vendeur) ou spéciales.

Hum... J'aime les senteurs de l'ambition dans le matin. Cela sent comme ... la hiérarchie.

Les UTIs s'organisent en une structure arborescente, où chaque nœud est sensé se conformer à ses nœuds parents. Tous les JPEGs sont des fichiers image, tous les fichiers images sont des fichiers de données, et ainsi de suite; MIME a essayé de créer une hiérarchie similaire, sous le préfixe "image/...". Mais comme je l'ai dit précédemment, cela se comporte plutôt mal quand des formats de fichiers spécifiques à un vendeur y sont mélangés, et le nombre et l'étendue des types de niveau supérieur ne sont pas très satisfaisants non plus.

De mon point de vue, la découverte principale (l'idée essentielle, si vous voulez) des UTIs, est qu'ils différencient la hiérarchie à l'intérieur de chaque UTI, de la hiérarchie de tous les UTIs l'un par rapport à l'autre. Voici la base.

Les UTIs sont des chaînes de caractères qui peuvent contenir des nombres, des lettres, des tirets et des points, plus n'importe quel caractère unicode au delà du jeu ASCII. Les types standard ont un préfixe "public.". On les appelle aussi des "identificateurs publiques", et seul Apple peut les définir. Les UTIs créés par quiconque d'autre que Apple doivent (surprise !) respecter le style de noms en DNS inverse (comme "com.adobe.pdf").

Chaque UTI peut "hériter de" ou "se conformer à" tout autre UTI. Ci-dessous, voilà un exemple de hiérarchie d'identificateurs de type uniforme.
listing

On voit ici que les fichier HTML "public.html" et les fichiers de texte simple "public.plain-text" sont tous les deux des formes de fichiers texte (public.text). A leur tour, tous les fichiers texte sont aussi des fichiers de données (public.data), et ainsi de suite. Notez encore que la hiérarchie à l'intérieur de noms d'UTIs n'a absolument rien à voir avec leur position dans l'arborescence. L'UTI com.mycorp.myspecialtext est un type de fichier de texte simple, mais le nom de l'UTI ne commence pas par "public.", à la différence de public.plain-text.

Rappelez-vous aussi que public.data n'est en aucune façon le sommet de l'arborescence, et qu'il n'y a pas une seule racine. Chaque UTI qui n'hérite pas d'un autre UTI peut être considéré comme racine.

Les UTIs peuvent aussi hériter de plusieurs parents, comme dans le cas des paquetages d'applications (les dossiers spéciaux qui apparaissent comme de simples icônes d'applications dans Mac OS X. Les paquetages d'application sont à la fois des "bundles" et des "packages").
listing

Les applications déclarent leurs UITs dans leurs fichiers Info.plist (des listes de propriétés XML) à l'intérieur de leurs paquetages d'applications.. Il y a deux sortes de déclarations, "exported" et "imported".

Les UTIs exportés sont rendus disponibles pour tout le système. Une application qui a son propre format de fichier doit avoir une déclaration UTI "exported" qui décrit ce format.

Les UITs importés déclarent des UTIs qui n'appartiennent pas à l'application, mais qui ont besoin d'être connues par le système pour que l'application puisse faire son travail. Par exemple, imaginez qu'une application qui fait des modifications sur des fichiers Adobe Photoshop. Une telle application doit continuer à fonctionner même si Photoshop n'est pas installé sur le système.

Pour que Mac OS X puisse, par exemple, gérer des glisser-déposer pour cette application, elle doit comprendre que le fichier qui est déposé est un fichier Adobe Photoshop. Mais si Photoshop (qui a une déclaration "exported" pour le format de fichier Photoshop com.adobe.photoshop) n'est pas installé, comment le système va-t-il savoir ce qu'est un fichier Photoshop ? Pour résoudre ce problème, l'application qui modifie le fichier Photoshop inclut une déclaration d'UTI "imported" pour com.adobe.photoshop dont l'objet principal est de "pré-déclarer" l'existence et la nature de l'UTI de fichier Photoshop, même si Photoshop n'est pas installé.

Dans le cas où une déclaration d'UTI exporté entre en conflit avec une déclaration d'UTI importé, la déclaration exportée a la préséance. C'est normal, puisque la déclaration exportée est faite par l'application qui "possède" l'UTI. Quand elle est installée, la déclaration d'UTI importée n'est plus nécessaire, de toute façon.

Une déclaration d'UTI contient les informations suivantes :
• La chaîne UTI elle-même.
• La liste des UTIs dont elle hérite.
• Une liste de types d'identificateurs alternatifs, qui sont équivalents pour cet UTI (extensions de noms de fichiers, types MIME, etc...).
• Un chemin vers le fichier de l'icône de l'application dans le paquetage de l'application, utilisé pour afficher des fichiers de même type.
• une description optionnelle, directement lisible, et localisable.
• l'URL du document qui décrit l'UTI.

La liste des types "équivalents" est utilisée pour fournir des APIs de conversion d'un type vers un autre. Comme vous pouvez l' imaginer, il est tout à fait possible que n'importe quelle extension de nom de fichier, code type sous Mac OS classique, ou type MIME puisse se résoudre par plus d'un UTI. L'API de conversion accepte des "conseils" pour en choisir un (par exemple, ne prends en compte que les sous-types de public.data parce que j'ai récupéré cette extension de nom de fichier d'un fichier, pas d'un dossier ou d'un autre type d'entité). Si elle n'a pas de conseils, l'API préférera les identificateurs publics aux autres.

Dans le cas où il n'y a pas d'UTI satisfaisant pour un item, un UTI est créé dynamiquement. Ces UTIs commencent par le préfixe "dyn." et sont là pour garantir que tout dans le système a une forme d'UTI unique, même si cela n'a qu'une signification temporaire.

Les développeurs sont poussés à utiliser des identificateurs publics, à moins que des UTIs propriétaires dont ils veulent hériter ne soient définis dans la même application (ou, éventuellement, dans une autre application faite par la même compagnie).

Apple a publié une liste de presque 100 UTIs prédéfinis, qui couvre une énorme gamme d'entités. En voici seulement quelque exemples.
listing

Comme vous pouvez le voir, rien n'est à l'abri des UTIs. Apple a aussi inclus des déclarations d'UTIs pour décrire les autres systèmes de types de données.
listing

Comme un homme dans un habit orange de Péramèle, a dit un jour, "Parfait Mémé, parfait". ("Booya, Grandma! Booya!").

Pour résumer

C'est simple. Quand il faut identifier de façon unique des types de données, les types MIME, des codes type et créateur, et les extensions de noms de fichiers sont tous en défaut, et la seule règle, c'est les UTIs. Les types MIME et les codes type et créateur peuvent être de meilleurs systèmes d'identification de types que les extensions de noms de fichiers, (notamment quand il s'agit de localisation de stockage), mais ils souffrent de beaucoup des mêmes problèmes. Regardez simplement quelques uns des exemples ci-dessus, et voyez combien de codes type et de types MIME différents signifient la même chose : 'MPG', 'MPEG', video/mpg, video/mpeg, video/x-mpg, video/x-mpeg. Ce ne sont pas seulement les extensions de fichiers qui souffrent du manque d'unicité.

Les UTIs effacent l'ardoise, et apportent de nouvelles possibilités au festin. La seule manière évidente selon laquelle les UTIs pourraient être améliorés, serait de devenir un standard ouvert plutôt qu'un système entièrement administré par Apple et utilisé seulement dans Mac OS X. Mais en fait, cela ne serait que glacer le gâteau. Tant que des valeurs de n'importe quel système de définition de types de données peuvent être associées à des UTIs, le système de définition de types que les autres OSs utilisent importe peu. On peut espérer qu'ils pourront finalement converger, mais en attendant, Mac OS X Tiger dispose d'un système de définition de types de données puissant, extensible, qui dépasse largement ses prédécesseurs.

Un beau standard ne sert à rien si on ne l'utilise pas, bien sûr. J'espère que toutes les APIs de Mac OS X vont lentement migrer pour utiliser les UTIs comme moyen préféré de définition du type des données. En fait, rappelez-vous quand je disais que Spotlight utilise un greffon d'importation de méta-données pour chaque type de fichier. Et bien, les "types de fichiers" que Spotlight utilise pour associer chaque fichier à un greffon d'importation particulier sont en réalité des UTIs. Chaque greffon d'importation doit indiquer une seul UTI qu'il est capable d'indexer. La hiérarchie d'UTIs intervient quand Spotlight choisit les greffons d'importation les plus spécifiques pour chaque fichier, sur la base de la meilleure association entre l'UIT du fichier, et les greffons d'importation (plusieurs éventuellement) disponibles pour l'application.

Tiger contient déjà des APIs pour convertir les anciens types de données en UTIs (dans les deux sens). Les développeurs peuvent commencer à changer leurs applications pour utiliser exclusivement les UTIs, quand ils prennent leurs décisions sur les types de fichiers. Apple semble encourager cela.

Malheureusement, les UTIs n'existent que comme un concept interne aux applications. Apple a choisi de ne pas franchir le pas suivant (pourtant évident), et de ne pas séparer la représentation externe du type de fichier de l'extension de fichier. Les extensions de noms de fichiers sont de loin le plus mauvais système de définition de type, mais c'est aussi celui qui est le plus utilisé. Je ne me suis jamais opposé à l'utilisation et au support que Mac OS X fait des extensions de fichiers (et je les ai en fait utilisés). La terrible faute faite par Apple fut d'ériger les extensions de fichiers comme moyen "standard" de définition du type de fichier dans Mac OS X.

Avec les UTIs, Apple vient de retourner au moins la moitié de cette décision. En interne (dans les applications et dans l'OS), les UTIs sont maintenant le standard recommandé, pas seulement pour les définitions de types de fichiers, mais pour les définitions de types en général.

Mais en externe, les extensions de noms de fichiers sont encore le seul système obligatoire de type de fichier d'après les règles d'interface d'Apple. C'est une honte, parce que avec l'arrivée des attributs étendus, Tiger a la possibilité de stocker les UTIs avec chaque fichier, comme identificateur "officiel" de type de fichier. Apple a simplement choisi de ne pas recommander cette pratique.

Ce qui est intéressant, c'est que les codes type et créateur sont déjà (de façon redondante ?) stockés de cette façon dans Tiger. Les associer à un fichier crée une nouvelle clé d'attribut étendu, com.apple.FinderInfo avec une valeur qui est la concaténation des codes type et créateur. Cela se fait de façon transparente à chaque fois qu'un code type ou créateur est assigné à un fichier.

Avec les APIs de conversion, tout est maintenant en place pour que les UTIs soient officiellement érigés en système externe de définition du type de fichier dans Mac OS X. Les extensions de noms de fichiers pourraient être relégués au statut "d'optionnel, mais mis par défaut". Finalement, le nom de fichier reviendrait entièrement sous le contrôle de l'utilisateur, comme cela aurait dû être le cas depuis le début.

Tout cela reste un rêve, au moins, mon rêve. En même temps, c'est consolant de voir un peu de changement sur ce sujet dans Tiger. On l'attendait depuis longtemps. Ce qui a été fait dans Tiger a été bien fait. Bien que ce soit moins que ce que j'aurais voulu, c'est plus que ce que j'attendais. J'espère seulement que la tendance va continuer.