John Siracusa

Lion (14)

Les révisions de documents.

Le modèle de document modernisé de Lion repose largement sur la possibilité de gérer de multiples versions d'un seul document. Vu isolément à travers l'interface utilisateur, cela semble magique. A la différence des incarnations précédentes d'autosave, vous ne verrez pas les fichiers créés automatiquement apparaître ou disparaître à côté du document original. Mais les données doivent être évidemment stockées quelque part, alors, où sont-elles ?

En dépit de tous ses défauts, le système de fichiers de Mac OS X a en fait plusieurs caractéristiques qui pourraient être utiles pour enregistrer de multiples versions des fichiers. Une méta-donnée de numéro de version pourrait être stockée dans un attribut étendu ; on peut concevoir que le fichier de données lui-même soit stocké dans des fichiers d'allocation ; la méta-donnée existante invisible pourrait être utilisée pour cacher des versions multiples.

Bien qu'Apple se soit convertie aux méta-données du système de fichiers ces dernières années, pour s'appuyer massivement sur des attributs étendus dans l'implémentation de Time Machine, de quarantaine des fichiers téléchargés, et de listes de contrôle d'accès, les méta-données, survivantes de Mac OS classique, ne sont pas encore en cour. Si l' implémentation de Spotlight nous a appris quelque chose, c'est que pour le moment Apple préfère garder les choses simples quand cela concerne le système de fichiers.

Etant donné tout cela, je n'ai pas été surpris de trouver un répertoire /.DocumentRevisions-V100 caché à la racine de mon disque de démarrage, juste à côté du répertoire /.Spotlight-V100. A l'intérieur, vous y trouverez un fichier de base de données SQLite /.DocumentRevisions-V100/db-V1/db.sqlite qui contient des tables pour pister des fichiers, les versions individuelles de ces fichiers (que Apple appelle des "générations"), et l'emplacement de stockage des données. Pour les curieux, voici le schéma.

A la différence de Time Machine, le système de stockage d'une version de fichier par Apple ne se limite pas à sauver une copie complète de chaque nouvelle révision du fichier. Une seconde base de données SQLite (/.DocumentRevisions-V100/.cs/ChunkStoreDatabase) traque les morceaux qui diffèrent d'une révision du fichier à une autre. (L'examen de son schéma est laissé au lecteur comme exercice. Rappelez-vous seulement de copier le fichier de la base de données à un autre emplacement, et de lancer le programme sqlite3 sur la copie, et pas sur la base réelle, qui de toute façon, est vraisemblablement verrouillée).

La coupure intelligente de fichiers en morceaux, de telle façon que seulement quelques morceaux changent d'une révision à une autre est en fait un problème vraiment difficile. Considérez un fichier de 10 Mo coupé en dix morceaux de 1 Mo. Maintenant, imaginez que la révision suivante du fichier ajoute simplement deux octets au tout début du fichier. Si la nouvelle révision était naïvement coupée en dix morceaux égaux, chaque morceau serait différent de ceux créés précédemment, ce qui ferait échec au but poursuivi en coupant le fichier en morceaux, plutôt que de sauver des copies complètes à chaque fois.

Une des techniques utilisées par Apple pour aborder ce problème est appelée Rabin fingerprinting (empreinte digitale du Rabin). Les morceaux du fichier sont choisis sur la base de leur contenu plutôt que sur leur place à l'intérieur du fichier. Le titre de l' article de recherche qui a introduit cette technique, Un système de fichiers de réseau à faible bande passante suggère qu'il pourrait être utile pour, disons, un système de stockage de fichiers sur le réseau. Hum.

Pourtant, cet algorithme n'est pas appliqué aveuglément à tout fichier. Le moteur de stockage des morceaux connaît la structure interne de beaucoup de formats de fichiers courants, (par exemple les images JPEG, les vidéo MPEG4, les PDFs) et peut les couper en morceaux intelligemment sur la base de cette connaissance, en séparant les entêtes et les pieds, en trouvant les limites entre les éléments internes, et ainsi de suite. A la différence de Spotlight; il ne semble pas y avoir de sytème de greffon pour rajouter un support explicite à de nouveaux types de fichiers. Les types de fichiers personnalisés sauvés par des applications tierces semblent laissés aux caprices de l'empreinte digitale du Rabin.

Les très petits fichiers (disons, en dessous de 32 Ko) ne semblent pas du tout être coupés en morceaux. La découpe n'est pas nécessairement immédiate quand un fichier est sauvé. Cela peut arriver plus tard. De très gros fichiers sont généralement coupés en morceaux plus gros, pour éviter la situation où un ficher de 2 Go produirait des milliers de morceaux. Ce nouveau spectacle est joué par un nouveau framework privé, GenerationalStorage.framework, qui inclut un démon appelé revisiond.

(Il existe ici une opportunité intéressante pour un développeur tiers de créer une application "non autorisée" qui permette de naviguer dans le contenu du magasin des générations, peut-être même en bidouillant un nouvel item de menu contextuel du Finder pour lister les révisions précédentes d'un fichier sélectionné. Une application de ce genre ne serait sans doute pas autorisée sur le Mac App Store, et elle est susceptible de ne pas fonctionner à la prochaine révision de l'OS, mais elle peut encore trouver assez de clients pour valoir le coup).

Le système de stockage générationnel d'Apple est un mélange intéressant de technologies à toute épreuve (SQLite, démons, fichiers et répertoires normaux) avec tout juste assez d'habileté pour éviter un fardeau inutile au système en fonctionnement. Et rappelez-vous que tout fichier individuel créé dans le système n'est pas automatiquement passé en version. Le stockage générationnel est une caractéristique que les développeurs doivent utiliser explicitement. J'espère bien que beaucoup d'entre eux le feront.

L'indépendance à la résolution.

L' indépendance à la résolution est annoncée "pour bientôt dans Mac OS X" depuis 2005. Le rêve de pouvoir dessiner les mêmes éléments d'interface avec la même taille visible, mais avec plus de pixels, était si proche en 2007 que nous avons pu y goûter. Puis quand Snow Léopard est arrivé, les capacités de changement d'échelle de l'interface du Mac avaient effectivement régressé. Navrant.

En même temps, je jumeau du système d'exploitation de Mac OS X a valsé sans problèmes dans une IU à haute résolution dès ses premiers pas. Le secret d'iOS ? Ne pas essayer de supporter des facteurs d'échelle arbitraires, en supporter un seulement, la double résolution. Un carré de 50 x 50 pixels sur l'écran non-rétina d'un iPhone est exactement de la même taille qu'un carré de 100 x 100 pixels sur un écran rétina. Les graphiques qui n'ont pas été mis à jour pour une résolution plus élevée sont simplement dessinés avec des carrés de quatre pixels à la place de chaque pixel en basse résolution. Toutes les dimensions sont conservées, des multiples entiers l'un de l'autre. C'est une adaptation parfaite pour des écrans physiques qui, bien sûr, ont un nombre entier de pixels. Des mesures fractionnaires nécessitent obligatoirement d'affreux compromis.

Lion a retenu la leçon de son jeune frère. Le changement d'échelle arbitraire a disparu. A la place, il y a une seule boîte de réglage pour définir les modes d'affichage "HiDPI". (Cette option est encore cachée dans l'application Quartz Debug, si bien que ce n'est clairement pas une caractéristique pour l'utilisateur final). Mais, à la différence des précédentes incarnations de l'indépendance à la résolution, celle-ci fonctionne vraiment.

Les modes d'affichage HiDPI sur un Mac Book Pro de 15 pouces (résolution native 1440 X 900).

Après avoir validé HiDPI, les nouveaux modes d'affichage deviennent disponibles. Dans l'image ci-dessus, le mode 720 x 450 est la moitié des dimensions de l'écran natif, et le mode 640 x 400 est la moitié du réglage (non natif) en 1280 x 800. Après avoir sélectionne un mode HiDPI, tout est dessiné avec deux fois plus de pixels que dans son équivalent non HiDPI . Voici une copie d'écran qui montre TextEdit; notre bête de travail habituelle pour la mise à l'échelle de l'interface.

TextEdit sous Lion en mode "HiDPI".

C'est plutôt bien, non ? Les seules imperfections sont les graphiques bitmap qui n'ont pas été mises à jour pour le HiDPI (regardez de près les triangles noirs de la règle). Malheureusement, il y en a beaucoup de ce genre partout dans le système d'exploitation et dans les applications fournies. Mais à la différence des années passées, le framework est finalement disponible pour les développeurs tiers, et Apple elle-même a enfin rendu ses applications prêtes pour un monde dans lequel un bureau et des affichages de portables à 300 ppi sont plus que des curiosités coûteuses.

A la différence d'iOS, Mac OS X doit surmonter une variété beaucoup plus grande de tailles d'affichage. Jusqu'à présent, il n'y a pas d'équivalent Mac à l'iPhone 4 arrivant avec un affichage en double densité, et se vendant rapidement à un nombre d'unités tel qu'il représente une portion significative de la base installée. Néanmoins, la facilité avec laquelle les développeurs d'iOS se sont adaptés à l'affichage rétina me rend confiant que l'approche du doublement des pixels peut fonctionner aussi sur le Mac. Il nous faut attendre un peu plus longtemps. Nous y somme déjà accoutumés.