Foxmarks: Heuristiques de synchronisation
From Foxcloud Wiki
Cette page donne des indications sur la manière d'améliorer la procédure de synchronisation automatique.
Contents |
État actuel
Nous avons décidé d'implémenter les heuristiques de synchronisation décrites ici, mais nous attendons que l'équipe Cosmo fournisse le support des Etag (balises-entitées) pour les cas de coïncidence ou de non-coïncidence. Ils comptent l'intégrer dans la prochaine version de maintenance, la semaine du 7/11/2005. D'ici là, la manière de procéder reste la même.
- Cela fonctionne apparemment sur Cosmo 0.2.2, nous nous préparons donc à présent à déployer cela. Une partie des modifications consistera en premier lieu à "nettoyer" l' algorithme de premier niveau.
Proposition actuelle
Le but principal décrit ici est de rendre l'utilisation de Foxmarks plus aisée. L'opération de synchronisation est plutôt "lourde", en particulier pour les utilisateurs ayant beaucoup de marque-pages (notre client idéal). La manière avec laquelle nous avons implémenté la synchronisation automatique présente des inconvénients.
L'approche décrite ici comporte deux aspects : elle offre un meilleur choix que de "synchroniser au démarrage et à l'arrêt" pour la synchronisation automatique et rend l'opération de synchronisation beaucoup plus "souple".
Options de synchronisation automatique
Dans les anciennes versions de Foxmarks, nous avions une option "minuteur" dans l'interface utilisateur qui n'a jamais été implémentée. Je propose de la faire renaître de ses cendres. On ajouterait à l'interface utilisateur un champ dans lequel l'utilisateur pourra définir la fréquence de synchronisation automatique, probablement en minutes. Lorsque Firefox est en cours d'utilisation, Foxmarks tentera de synchroniser automatiquement toutes les x minutes, où x est la valeur définie par l'utilisateur précédemment.
Les options "Au démarrage" et "À l'arrêt" pourraient donc être révisées. À l'arrêt, par exemple, nous pourrions faire faire une vérification pour effectuer une synchronisation uniquement lorsque le dossier contenant les données est "sale" (a été modifié). Lorsqu'on arrête Firefox, vous n'avez pas besoin de vérifier si le fichier sur le serveur a été modifié mais vous devez être sûr que les modifications effectuées lors de la session aient été envoyées vers le serveur. Si l'utilisateur n'a procédé à aucune modification, cette option sera entièrement silencieuse.
J'ai modifié légèrement l'option "Au démarrage" afin d'éviter la synchronisation tant que x minutes ne sont pas passées depuis la dernière synchronisation enregistrée. Je le rappelle, ceci évite une synchronisation complète durant les x minutes et permet d'effectuer une synchronisation rapide au démarrage la plupart du temps (voyez ci-dessus) mais garantit que vous obtenez la dernière version du serveur.
Rendre la synchronisation moins gourmande en ressource
Le meilleur compromis est d'utiliser les ressources réseau de manière optimale, puisque c'est à ce niveau-là que l'on risque de perdre en efficacité. Avant de procéder à une synchronisation, nous pouvons déterminer si le fichier sur le serveur a été modifié puisque une balise-entité (Etag) a été stockée lors de la dernière modification du fichier. Nous ne recherchons le fichier que si l'Etag ne correspond plus.
Si l'Etag correspond, ce qui se passe par après dépend de l'état ("sale") du stockage des données locales. Si ce stockage est "propre", il n'y a rien à faire. Si ce stockage est "sale", nous enregistrons sur le serveur une copie des données locales (en mettant à jour la date de dernière modification de chaque élément, bien entendu).
Si l'Etag ne correspond pas, nous devons rechercher le fichier complet. Nous pourrions faire une synchronisation standard à ce moment-là. Bien que nous pourrions probablement éviter quelques cycles en copiant le fichier simplement vers le stockage de données local s'il est "propre", cela ne me paraît pas être une bonne méthode. En fait, si le stockage local est "propre", nous ne voulons pas modifier le fichier sur le serveur après une synchronisation. Ce n'est pas seulement parce qu'il n'y a aucune raison de le modifier (comme il sera non-modifié par définition), mais aussi parce que cela modifiera l'Etag, ce qui forcera les autres clients de lire le fichier, qu'il devront modifier, etc...
Notes internes
Le but est de rendre la synchronisation la plus transparente possible tout en utilisant de manière raisonnable les ressources réseau.
Dans un monde idéal, chaque fois qu'un utilisateur modifie un marque-page, cette modification serait instantanément répercutée au serveur puis aux autres machines clientes. Il y a au moins deux raisons pour lesquels cela n'est pas faisable. Premièrement, nous n'avons aucun système qui notifie cela, ainsi les clients seraient obligés de vérifier régulièrement s'il y a quelque chose à télécharger.
Deuxièmement, nous n'avons pas encore de moyen pour détecter l'absence de modifications dans le fichier sur le serveur sans téléchargement du fichier entier. (Je présume que cela pourra être adressé aux serveurs webDAV via des Etags ou des Si-modifié-depuis.)
Enfin, même si nous pouvons demander au stockage des données local de contrôler les modifications, nous devons prêter attention au traitement des marque-pages dynamiques, puisqu'ils changent fréquemment par définition, mais ces modifications-là ne devraient pas être répercutées.
C'est pourquoi, je vous demande de réfléchir aux considérations suivantes :
1) Lorsqu'une modification a eu lieu en local, démarrer le minuteur. Si une autre modification en local a lieu, démarrer à nouveau le minuteur. Lorsque le minuteur arrive en fin de décompte, procéder à une synchronisation. Si le navigateur est arrêté avant la fin du décompte du minuteur, procéder à une synchronisation.
2) Périodiquement, sonder le serveur à la recherche de modifications -- cela voudrait simplement signifier, procéder à une synchronisation, certes, mais qui s'interrompt si le serveur indique que le fichier n'a pas été modifié depuis la dernière synchronisation. (Cela ne peut être fait par une Etag). Si au démarrage, nous constatons que nous avons pris plus de temps que notre intervalle de sondage désiré sans synchronisation, invoquer une synchronisation (après un délai convenable pour éviter les problèmes de démarrage).
- Okay, après y avoir réfléchi un peu, j'ai une vue légèrement différente sur l'implémentation. Premièrement, oublier l'observation des modifications. Rendre l'opération de synchronisation la plus souple possible pour la plupart des cas et procéder à la synchronisation régulièrement. Tout d'abord, vérifier s'il y a des modifciations au niveau local en créant la liste ds éléments "sales". Si cette liste est vide (c'est à dire que le stockage des données local est "propre"), insérer une Etag dans le fichier sur le serveur. S'il revient sans modifications, rien ne sera fait. Si le stockage des données local est "sale" ou l'Etag du fichier serveur ne coïncide plus nous serons dans l'obligation de procéder à une synchronisation complète.
- Procédure spéciale à l'arrêt : si le stockage des données locales est "sale" à l'arrêt, procéder à une synchronisation complète.
- Procédure spéciale au démarrage : si le fichier serveur est sale au démarrage, procéder à une synchronisation complète.
- Davantage d'optimisation : si, lors d'une synchronisation, nous voyons que l'Etag coïncide avec ce que nous avons habituellement, ne pas s'embêter à télécharger le fichier ; ne modifier (avec les dates-des-derniers-éléments-modifiés) que le fichier local.
- Il semblerait qu'une petite restructuration du code de synchronisation de premier niveau soit requise ; la synchronisation doit être mieux intégrée dans les opérations sur le réseau, ce qui est couramment ignoré. Ce n'est pas grave ; il faut juste la placer correctement.
--Todd 17:46, 31 October 2005 (EST)
-- Traduit par Jojaba le 2/06/06
