Discussion:Programmation XML/SyncML

A propos des ancres

Citation:

Durant la synchronisation, le client et le serveur ont besoin de connaître les champs à mettre à jour. Ils utilisent pour cela les ancres de 
synchronisation ou encore Sync Anchor qui vont permettre de déterminer quels sont les champs qui ont été modifiés depuis la dernière synchronisation, 
et donc quels champs doivent être mis à jour.

Les ancres ne servent pas à déterminer les modifs, mais servent à savoir si la derniere synchro s'est bien passée. Au début de session, le client envoie ses ancres (last et next). Le serveur stock la next du client. A la fin de la session (si y pas eu d'interruption), le client update ses ancres (last = next et il incrémente next). Lors de la prochaine session, le client envoie son next et last. Le serveur verifie que le last du client vaut le next qu'il a stocké précédemment. Si c'est le cas, ca rox, on continue. Sinon ca va pas du tout et le serveur PEUT forcer une slow sync.

Session 1: C'est une slow sync: le client envoie juste son next. La synchro se passe nickel

Client                     Serveur
 |---------next=1------------>|        next client = 1
 |
 |
 |
 |

Fin de synchro: last=1, next=2

Session 2: Une interruption se produit lors de cette synchro

Client                        Serveur
 |--------last=1, next=2------>|          last = next stocké (1). next client devient 2
 |                             |
 |
Interruption

Comme la session va pas au bout, le client update pas ses ancres

Session 3 Apres l'interruption on essaye de repartir

Client                      Serveur
 |------last=1, next=2------>|          CA MATCH PAS: 1!= 2 La derniere synchro s'est mal passée!! Le serveur peut demander une slow sync
 |

A propos de la section "Synchronisations (Syncs)"

  2. Slow sync (Synchronisation lente) - Une synchronisation à double sens dans laquelle tous les champs de la base de données 
sont vérifiés par une méthode basique champs-à-champs. Ce type synchronisation est utilisée lorsqu'il y a une forte latence entre
le client et le serveur.

Ce qu'il faut surtout retenir c'est que le client renvoie l'intégralité de ses données. Le serveur calcule le delta (avec les siennes) et le renvoie au client.

  3. One-way sync, client only (Synchronisation uni-directionnelle, Client uniquement) - Le client transmet ses modifications en premier. 
Le serveur les accepte puis met à jour les données sans transmettre en retour ses modifications.

Ben vi le client transmet ses modifs en premier.... vu qu'il est le seul a en envoyer....

  4. Refresh sync from client (Synchronisation de mise à jour initiée par le client) - Le client transmet sa base de données 
entièrement au serveur. Le serveur n'effectue pas de synchronisation. Parcontre, la base de données cible est tout simplement 
remplacée par celle transmise par le client.

La synchro est toujours initié par le client!!!! Le serveur effectue la synchronisation... C'est son boulot merde...

 5. One-way sync, server only (Synchronisation uni-directionnelle, Serveur uniquement) - Le serveur transmet ses modifications 
en premier. Les client les accepte puis met à jour ses données locales sans transmettre en retour ses modifications.

Le serveur ne transmet jamais ses modifs en premier... Dans ce cas là c'est juste que le client n'envoie pas de modif vu qu'on est en "one way from server"

  6. Refresh sync from server (Synchronisation de mise à jour initiée par le serveur) - Le serveur transmet l'intégralité 
des informations de sa base de données. La base de données du client est entièrement remplacée.

Le serveur initie jamais la synchro. Il peut en demander une via une notif (sas), mais il ne sera jamais initiateur de la synchro.

  7. Server alerted sync - Le serveur télé-commande au client d'initier un des modes de synchronisation présentés ci-dessus. 
De cette façon, le client est controllé à distance par le serveur.

Faux!!!!!!! le serveur ne controle rien. Le client a parfaitement droit de refuser de synchroniser lors de la reception d'une notif

A propos de la définition de syncml

Le protocole SyncML a été conçu en gardant ces objectifs à l'esprit :

   * En tant que langage commun, n'importe quel terminal doit être capable de se synchroniser avec n'importe quel service (données du réseau).
   * N'importe quel service supportant SyncML doit être capable de se synchroniser avec n'importe quel teminal utilisant SyncML.
   * Le protocole doit prendre en compte les limitations des terminaux mobiles, en particulier les capacités de stockage.
   * Il doit supporter un large panel de protocoles comme HTTP, SMTP, Bluetooth et bien plus.
   * Il doit envoyer des mêmes commandes de synchronisation à tous les terminaux.
   * Il est construit à partir des technologies web existantes, en particulier XML.
   * Il doit supporter des communications asynchrones et la gestion d'erreurs en raison de la latence d'Internet.

SyncML comprend des commandes client et serveur définies par des DTD...

Ce qu'il faut retenir de syncml:

Il permet de garder en cohérence deux ensembles de données
Il est indépendant du transport (enfin je demande a voir pour du smpt, comme marqué dans l'exemple ;-) )
Il est indépendant de la données synchronisées (PIM, email, fichier, ....)

A propos de la section Messages et Packages

Les messages SyncML sont des requêtes d'un client ou d'un serveur pour demander l'exécution d'une action. Cette action peut être la synchronisation 
de  données, des vérifications sur les données, la mise à jour d'un état ou la gestion de n'importe quelle erreur avec ces actions. Les messages 
sont  regroupés en packages comme un genre de liste de tâches. Les messages sont une liste de requêtes et peuvent être traités dans le désordre 
si suffisamment d'informations sont fournies afin d'identifier le package auquel le message appartient.

Ca veut pas dire grand chose tout ca... Un message: Un ensemble de commandes syncml transmis (en une seule fois) vers le client ou le serveur. La taille max d'un message est défini par la Meta données MAxMessageSize. Si un message à transmettre dépasse cette taille on le découpe en plusieurs message. On parle alors de Multiple Message in Package. Un package correspond à un ensemble de messages pour effectuer une des etapes de la synchro Les packages sont les suivants: pkg1 = init (authent, echange des devinf, des informations sur les bases à synchronisés) pkg2 = Modif client pkg3 = modif serveur pkg4 = mapping des ids client et serveur

SyncML est conçu pour supporter les erreurs et les messages perdus. Si un message est perdu, un client ou un serveur SyncML saura 
qu'il y a un problème   puisque le mapping ne peut pas être fait. Il va alors effectuer une requête pour demander que l'information 
soit ré-émise. Une fois les données reçues,  la mise à jour des informations peut être faite.

?? de quel mapping on parle. Pour savoir si la derniere session s'est bien passée, on utilise le méchanisme d'ancre.

A propos de la section Structure d'un message SyncML

Le corps contient la requête actuelle, les alertes et les données.

Ca veut dire quoi la requête actuelle???? Le corps contient les commandes SyncML (les status des commandes du messages précédents, et tout les autres commandes prévues par syncml).

A propos Mapping ou Correspondance

Les LUID et GUID n'ont besoin d'être uniques que s'ils sont utilisés dans une table entre deux entités communiquantes. Ces nombres sont 
temporaires et utilisés pour faire une correspondance et n'existent que pour la durée des transactions entre le client et le serveur.

Nan mais ca va!! Les LUID et GUID sont affectés aux items tant qu'ils existent en base.

On comprend pas du tout l'interet des LUID et GUID la dedans... Apres tout pourquoi ne pas utiliser le meme id coté serveur et client pour pour meme item? A l'origine, c'est encore une histoire de capacité du mobile: Le serveur va potentiellement gérer un nombre enorme d'items (il va synchroniser tous les mobiles). Les ids auront donc une assez grosse taille. Ca peut paraitre con, mais ca prend de la place. Surtout dans le cas ou le client va juste gérer une centaine d'items. Ca laisse aussi la possibilité de gérer ses propres ids sans se prendre la tete. C'est le serveur qui a partir des ids du client sait retrouve ceux dans la base coté réseau.

Des remarques à l'arrache

Dans "SyncML Example": A noter que le message présenté n'est absolument valide par rapport à la DTD syncml (meme s'il est vrai que la norme n'impose pas la validité des messages, y a des limites!!!)
Dans "SyncML Example": On parle pas de fichier syncml mais de message syncml
Dans "SyncML Example": Pour la ligne 10 c'est le status d'une commande syncml du message précédent. "Le status de l'application" ca veut rien dire
Dans "SyncML Example": On passe quand meme a coté du truc important... On a un élément Sync ligne 11. Ca veut dire qu'on est dans le package 2 ou 3: le client ou le serveur est en train d'envoyer ses modifs. Dans l'exemple le terminal demande la mise d'un item de la base de l'autre device, et rajoute un nouvel item.
Dans authentification. Ce n'est pas le serveur qui informe du type d'authentification utilisé... SyncML est pensé pour des terminaux a des faibles capacités... Si le client devait supporter tous les eventuels types d'authentification que le serveur pourrait eventuellement utilisés, on aurait pas fini. SyncML ne prévoit que 2 types d'authent: basic et md5.
Dans Initialisation de la synchronisation: Initiailisation fait partie du processus de synchronisation. Ce que vous appellez "synchronisation" est juste la phase d'echange des modifications (package 2 et 3).
A propos des change logs: "mais requiert que les modifications et corrections soient négociées entre client et serveur par l'intermédiaire de messages." <= Ca veut rien dire du tout cette phrase. Les change logs c'est juste une manière pour un device (client ou serveur) de déterminer la liste des modifications dans la base depuis la derniere synchro.
Dans "Adressage" LocUri pas DocUri.., IMEI et non pas IMEA...
Définition de message données: "La plus petite unité de balise SyncML"?? Pourquoi pas: Un ensemble de commandes syncml ainsi que leurs données et les meta-données relatives à un package syncml
Mapping - Utilisation d'un identifiant intermédiaire pour lier deux informations. Y a rien d'intermédiaire... On fait juste que mapper l'id client avec celui du serveur
"Spécifications de SyncML": "La meilleure source d'informations sur SyncML c'est le protocole lui-même. Allez voir le site de l'Open Mobile Alliance pour obtenir les spécifications de SyncML." Vi et l'auteur semble avoir oublié de s'y rendre :-D