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

Mountain Lion : la revue de Ars technica (10)

Là où Lion a trébuché, Mountain Lion regroupe et va de l'avant.

Par John Siracusa, 25 Juillet 2012


iCloud

Apple a révélé iCloud à la WWDC de 2011, plus d'un mois avant la sortie de OS X 10.7 Lion, si bien qu'il peut sembler étrange de discuter d'iCloud dans un rapport sur OS X 10.8 Mountain Lion.

Il est en réalité un peu bizarre de discuter de iCloud dans le contexte d'un système d'exploitation quel qu'il soit. iCloud n'est pas, à proprement parler un logiciel local. Il est installé sur des services de réseau qui tournent dans un essaim quelque peu nébuleux de serveurs Apple. Mais ces services ne deviennent utiles que quand des développeurs y accèdent en utilisant les APIs qu'Apple a ajouté à son système d'exploitation.

Apple a utilisé iCloud de façon extensive dans iOS 5, en libérant finalement les bidules mobiles d'Apple de la chaîne obligatoire à un iTunes en fonctionnement sur un PC ou sur un Mac. Sous Lion, iCloud a remplacé MobileMe comme méthode recommandée par Apple pour partager des données d'applications entre des Macs et des bidules iOS : contacts, calendriers, marque-pages, courriel, et autres.

Quelle place, dans ces conditions, Mountain Lion peut-il avoir dans l'histoire de iCloud ? Pour utiliser une des phrases favorites de Tom Cook, Apple "double en descente" avec iCloud dans Mountain Lion. Mais avant d'en arriver là, passons en revue ce que iCloud est réellement, dans la perspective des APIs.

Un nuage en trois parties.

Au sens large, iCloud est un lieu de partage de données. Les APIs d'Apple pour iCloud sont là pour donner l'illusion que toute donnée placée dans iCloud est présente "partout"- sur tous vos Macs et vos bidules iOS, et dans tout autre contexte où vous vous êtes enregistré(e) avec votre compte iCloud. L'utilisation du mot "ubiquitous" dans les noms des fonctions et des objets des APIs d'iCloud renforce cette idée. "Rendez ce document ubiquiste" signifie "rendez ce document visible sur tous mes appareils."

Du point de vue du développeur, les choses sont un peu moins magiques. Apple fournit trois formes différentes d'APIs pour le stockage des données sur iCloud, avec très peu de superpositions entre elles en termes de fonctionnalités et d'intentions. Pour ce que nous en savons, ces trois APIs ont été développées par trois équipes complètement différentes au sein d'Apple, et font tourner trois ensembles complètement différents de serveurs. Elles sont seulement regroupées sous le parapluie commercial dont le terme est "iCloud".

Key Value Storage (stockage de valeur par clé).

La première API de stockage d'iCloud s'appelle Key Value Storage. Elle est utilisée pour stocker de petites quantités de données structurées sous la forme de paires clé/valeur. Chaque application de Mountain Lion peut stocker jusqu'à 1024 paires clé/valeur pour un total maximum de 1 Mo de données. (Ce stockage de données de 1 Mo de paires clé/valeur par application ne compte pas dans le quota de stockage d'un utilisateur de iCloud).

Bien que cela puisse sembler peu, ces limites ont significativement augmenté depuis leur niveau sous Lion. Les applications peuvent aussi lancer plus de requêtes de service avant d'être embouteillées - jusqu'à 15 requêtes toutes les 90 secondes. Cela permet aux applications d'être plus réactives en aidant les modifications faites sur un appareil à être plus rapidement renvoyées sur les autres.

Le stockage de valeur par clé est idéal pour des choses comme les préférences utilisateur, l'information d'état simple d'une application (par exemple, les documents ouverts, les positions de fenêtres et de leur défilement, la sélection d'un état). Sa stratégie de résolution de conflits est adaptée à la granularité attendue des données et à la taille de l'ensemble. Disons simplement que la dernière modification est gagnante, "dernière" étant défini du point de vue des services de iCloud, quand des modifications sont intervenues sur divers appareils participants. Les applications sont encouragées à conserver une copie locale de cet ensemble de données pour le cas où elles voudraient ignorer comment un service iCloud a résolu un conflit et déclarer leur propre ensemble de données local comme le vrai "gagnant" en se basant sur l'activité actuelle de l'utilisateur.

Par exemple, imaginez un utilisateur occupé à un jeu sur un appareil qui n'a pas encore récupéré sur iCloud la liste des scores. L'utilisateur fait un haut score, et l'application définit cette valeur dans le stockage de valeur par clé, qui est alors envoyé à iCloud. Un autre appareil qui s'est auparavant synchronisé avec iCloud sait que ce nouveau score, qu'il vient juste de recevoir de iCloud est en fait plus bas que le plus ancien score élevé. Dans ce cas, l'application peut rejeter les dernières modifications reçues de iCloud et remplacer ce qu'elle sait être le score le plus élevé à sa copie locale des données préalablement synchronisées.

Le stockage de valeur par clé est en réalité disponible sans compte iCloud. Mais comme toutes les APIs qu'Apple met sous le parapluie d'iCloud, il n'est accessible qu'aux applications vendues sur le Mac App Store.

Le stockage de document.

Le stockage de document est ce à quoi les utilisateurs pensent sans doute le plus quand ils envisagent iCloud. Les APIs de stockage de document permettent à des fichiers et à des paquets de fichiers (des choses comme les fichiers .rtfd,qui sont en réalité des répertoires pleins de fichiers) d'être stockés sur les serveurs Apple au lieu de l'être localement sur le disque dur d'un Mac ou dans la mémoire flash d'un bidule iOS.

Dans les coulisses, les données du document envoyées à, ou récupérées de, iCloud sont en fait stockés localement sur des disques, bien sûr. Chaque application a quelque chose qu'Apple appelle un "conteneur d'ubiquité" (localisé dans ~/Library/Mobile Documents/... , mais vous n'êtes pas censé(e) le savoir).

Quand une application met un document dans son conteneur d'ubiquité, le service d'ubiquité de document de la machine fragmente le fichier en morceaux, et envoie ces morceaux aux serveurs d'iCloud. Plus tard, quand le document est modifié, seulement les morceaux qui ont été changés sont renvoyées aux serveurs iCloud. (Pour les lecteurs qui ont bonne mémoire, cela peut un peu ressembler au mécanisme introduit dans Lion pour gérer des révisions locales de document. Ce n'est pas une coïncidence).

Le démon des services de documents d'iCloud est très agressif quand il s'agit de pousser des méta-données (par exemple le nom la taille, la date de création) de fichiers vers le nuage, ou vers d'autres appareils clients d'iCloud. Cela peut arriver avant que les données effectives du fichier (qui peuvent être énormes) aient été envoyées vers le nuage.

Les données du fichier sont récupérées automatiquement par tous les Macs qui sont enregistrés dans le même compte iCloud alors que les bidules iOS ne récupèrent les données de fichiers que sur demande. Les bidules iOS sont avertis grâce à la propagation automatique des méta-données de tous les fichiers, mais c'est du ressort de chaque application iOS de réclamer l'envoi des données du fichier (par exemple, en réponse à une requête de l'utilisateur pour voir le contenu d'un document).

La différence de ligne de conduite repose sur la capacité supposée de stockage de chaque plateforme. Les Macs ont beaucoup plus d'espace de stockage que les bidules iOS. Mais quand les données d'un fichier ont été récupérées par une application iOS, les modifications de données du fichier qui interviennent par la suite sont automatiquement propagée au bidule iOS.

Le transfert des données de fichiers se fait aussi pair-à-pair quand c'est possible. Par exemple, si un Mac récupère un nouveau fichier à partir d'iCloud, un iPad qui est sur le même réseau local que le Mac peut réclamer ce même fichier au Mac plutôt que de l'importer d'iCloud par une connexion internet.

La résolution des conflits pour le stockage de documents iCloud suit le modèle de document introduit dans Lion. Pour chaque conflit sur un fichier, le service de stockage d'iCloud récupère automatiquement le "gagnant". Le "perdant" dans chaque conflit est sauvegardé comme version précédente du document et reste accessible à l'utilisateur à l'aide du navigateur de révision du document. Le gagnant est supposé être choisi sur la base des dates de modification, mais les détails exacts ne sont pas sous le contrôle de l'application.

Ce processus intervient même si l'application ne tourne pas, mais un conflit n'est pas considéré comme "résolu" tant que l'application n'a pas accepté ou rejeté le gagnant choisi par iCloud. Les applications ont accès aux détails du conflit, y compris aux méta-données pour le gagnant ou perdant choisi, comme le nom de l'appareil sur lequel chacun a été créé, et les noms des fichiers (pour le cas où une part du conflit résulterait d'un changement de nom de fichier). Cela peut servir à proposer à l'utilisateur une interface de résolution du conflit, ou bien l'application peut résoudre le conflit d'elle même en se basant sur cette information, sans ennuyer l'utilisateur.

Cette division du travail entre la détection du conflit, la sélection automatique du gagnant, et la résolution finale permet à une version complète et acceptable du fichier d'être disponible sur le disque aussi tôt que possible, sans réclamer d'intervention de l'utilisateur, et sans que l'application doive nécessairement tourner, tout en permettant aux application d'avoir leur mot de la fin sur la résolution du conflit.

Les APIs de stockage de document d'iCloud fournissent aussi un moyen de créer un URL à partir d'une révision particulière d'un document. Ces URLs sont associées à la version spécifique du document si bien que les modifications ultérieures dans le fichier ne modifient pas le contenu qui est téléchargé depuis l'URL. Ces URLs offrent une alternative possible à des choses comme des fichiers attachés de courriel, mais ce n'est pas une solution permanente pour le stockage de données dans le nuage : elles expirent après un certain temps non spécifié.