Introduction

Le blog mobile de l'amphi-gouri a été brièvement décrit, on peut aussi voir à quoi ressemble l'édition de billets sur petit écran.

Il s'agit ici de préciser comment la synchronisation fonctionne.

Utilisation, en images

Tout est stocké sur une carte CompactFlash. Quand on l'insère, OPIE fait automatiquement apparaître trois boutons dans l'onglet "application" : marche, arrêt, synchroniser (les icônes proviennent du moteur de dotclear et leur résolution est trop faible, ce sera arrangé :-). Ils mettent en marche et arrêtent les serveurs apache et mysql.

Un bref message informe que le démarrage ou l'arrêt s'est bien déroulé. Le bouton "sync" déclenche la cascade d'événements décrite plus bas.

Comment fonctionne la synchronisation

Définitions

Définissons les termes qui apparaîtront dans la suite.

• le permanent est le serveur web relié en permanence à l'Internet, qui sert les visiteurs du blog et recueille notamment les commentaires
• l' assistant est l'assistant personnel numérique (abrégé en PDA en anglais), machine mobile sur laquelle tournent les mêmes logiciels.
• un étalage est une copie exhaustive d'un ensemble d'information, sous une forme différente de sa forme native pour faciliter certains usages. En anglais on utilise le mot dump.

Le problème

Sur l'assistant et sur le permanent tournent un ensemble LAMP et le moteur de blog dotclear.

Une fois le blog déployé des deux côtés, se pose le problème de la synchronisation des bases de données. Une même base abrite les billets et les commentaires, L'un et l'autre peuvent changer de chaque côté. Le problème général est difficile et ne peut, je crois, se résoudre sans contrainte ni connaissance supplémentaire sur l'application qui utilise la base de données.

Dans notre cas, on remarque que les tables des billets et des commentaires ne sont pas indépendantes : dans chaque billet un champ indique le nombre de commentaires.

La solution

J'ai choisi une méthode qui a une assez bonne valeur de hack et qui évite de modifier l'application utilisant la base de données. Elle y gagne une certaine généralité mais qui n'échappe pas à quelques bricolages comme nous le verrons bientôt.

Le cas courant est que les billets sont édités sur l'assistant et les commentaires sur le permanent, mais on souhaite ne pas s'y limiter.

Un outil permet de fusionner des fichiers texte qui évoluent au cours du temps : CVS. C'est lui qu'on utilise. La référence de travail sera un étalage de la base sql au format texte.

Synchronisation en ligne

Quand je branche l'assistant sur son berceau et que je clique sur l'icône "synchroniser", voici ce qui se passe.

• étalage de la base sql de l'assistant dans un fichier texte (sur une carte CF)
• synchronisation par unison (donc sans fusion) et via ssh du dossier contenant l'étalage avec sa réplique (au sens de unison) sur le permanent.
• connexion ssh au permanent pour lui demander de réaliser les étapes qui suivent. (On oublie un instant la base de l'assistant, la suite tourne sur le permanent.)
  • étalage de la base du permanent
  • synchronisation (avec fusion) de cet étalage avec la référence CVS. La base CVS tient désormais compte des derniers changements opérés sur le permanent.
  • synchronisation avec fusion de l'étalage de l'assistant avec la référence CVS. Les deux tiennent désormais compte des derniers changements opérés des deux côtés. C'est ici que se passe la seule vraie fusion nécessaire des données.
  • resynchronisation (avec fusion) de l'étalage du permanent avec la référence CVS. L'étalage du permanent tient désormais compte des derniers changements opérés des deux côtés.
  • injection de l'étalage du permanent dans sa base de données qui se trouve donc à jour.
• (On a fini côté permanent, retour à l'assistant.)
• synchronisation par unison (donc sans fusion) et via ssh du dossier contenant l'étalage de l'assistant avec sa réplique sur le permanent. L'étalage sur l'assistant tient désormais compte des derniers changements opérés des deux côtés..
• injection de l'étalage sur l'assistant dans sa base de données qui se trouve donc à jour.

Alors tout est synchronisé.

Synchronisation hors ligne

L'intérêt de stocker l'étalage et les scripts sur une carte CF est que cela permet de réaliser une synchronisation hors-ligne, par un lecteur de carte CF si on n'a pas de berceau ni d'infrarouge pour le zaurus. Au lieu que l'assistant lance lui-même unison et ssh on lance les scripts avec une autre machine reliée à l'Internet et pouvant lire et écrire l'étalage sur la carte CF. La machine n'a pas besoin de savoir exécuter mysql puisqu'elle travaille sur les étalages plein texte.

Voilà pourquoi on peut dire qu'il s'agit d'un blog avec synchronisation en-ligne et hors ligne à double sens.

Détails techniques mais importants

Pour que tout se passe bien il a fallu "aider" CVS en "normalisant" les étalages à l'aide de sed. La même base doit produire le même étalage octet pour octet sur les deux appareils. Sinon, CVS croit voir des variations pertinentes là où il n'y a que des différences dans le format des étalages et cela génère des conflits lors de la fusion.

Limitations

CVS ne sait rien de ce qu'il fusionne mais il est capable de détecter les cas où sa compétence s'arrête. Le cas auquel je m'attend est celui où je crée un commentaire sur l'assistant (en réponse probablement à un autre) et qu'un visiteur en crée un autre sur le permanent. Ils vont être insérés au même endroit dans l'étalage et CVS annoncera un conflit.

L'ordre de synchronisation avec la base CVS a été conçu pour que le conflit se produise côté assistant (fixme), ainsi votre serviteur ne risque pas de perdre des commentaires de vous visiteurs. Pour minimiser les risques que cela se produire, il est bon de synchroniser aussi souvent que possible, de préférence avant et après chaque modification sur l'assistant.

Une autre limitation est qu'actuellement je ne verrouille pas les tables. Les opérations sur le permanent sont rapides mais pour plus de rigueur je placerai des verrous. Sinon une modification de la base pendant la synchronisation serait perdue. Côté assistant, il ne faut pas modifier le blog pendant qu'on synchronise. Bientôt des verrous partout où c'est pertinent.

La suite

Ça marche et c'est très bien. On pourrait fignoler. La méthode n'est évidemment pas performante dans le cas de grosses bases mais suffisante pour un blog ! On pourrait faire plus propre : mémoriser un journal de plus haut niveau (création de fiche et de commentaires) qu'on propagerait de façon plus légère.

Conclusion

Pour l'instant, je voulais pouvoir éditer mon blog avec un bon outil sur mon assistant Zaurus et le synchroniser avec le permanent, je suis satisfait. Comme le lecteur attentif s'en sera douté, ce billet a été essentiellement rédigé sur mon Zaurus, partiellement sur un ordinateur plus "traditionnel", en plusieurs fois, et synchronisé comme dit.