:Authors: Mano��l Fortun Specification pour une nouvelle gestion des versions des wikitty ---------------------------------------------------------------- Motivation ++++++++++ Dans le cadre de wikitty publication on peut synchroniser diff��rent wikitty service, ce qui implique que l'on peut ��tre amen�� �� d��ployer des wikittys avec une version diff��rente de 1.0 dans un autre wikitty service, qui lui n'ayant pas de version de ce wikitty le repassera en version 1.0, rendant sa version obsol��te d'office. De plus deux wikitty service peuvent arriver �� des num��ros de version similaire pour un m��me wikitty alors que ces deux wikitty auront ��t�� modifi�� chacun de leur cot��, posant un probl��me quand �� savoir quelle version doit ��tre celle que l'on doit prendre en compte. Pour cel�� une solution propos��e s'appuiera sur une notion de propri��taire de wikitty, et seul le propri��taire pourra changer la version majeur d'un wikitty. Solution ++++++++ Voici un diagramme qui montre une architecture de synchronisation entre wikitty. .. image:: graphDistrib.png On note l'apparition d'un champ owner dans les wikitty, il sert pour enregistrer lors d'une synchronisation de quel wikitty service viens le wikitty. On peut voir notre wikitty exemple qui �� chaque synchronisation rempli le champ owner en ajoutant �� la fin le dernier wikitty service propri��taire. Dans ce champ on enregistrera l'id du wikitty service, id g��n��r�� de la m��me fa��on que pour un wikitty, on s'assurera ainsi une unicit��. Le num��ro de version change aussi, ainsi seul le propri��taire pourra changer la version majeur du wikitty, et les autres wikitty service devront rajouter une version mineur �� chaque nouveau niveau de transfert. Ce qui signifie que si un wikitty service r��cup��re un wikitty qui �� d��ja deux propri��taire, ce wikitty service rajoutera un 3��me "niveau" de version mineur, comme on le voit sur le sch��ma. Lorsqu'un wikitty service recevra un wikitty, si il est dans la liste des propri��taires il v��rifiera son num��ro de version �� lui, si il est inf��rieur �� sa version courante qu'il poss��de il ne fera rien du wikitty, sinon il regardera les versions mineur et mettra �� jour sa propre version en incr��mentant son num��ro de version �� lui. Quelque soit le cas, pour un wikitty service il sait si il doit mettre �� jour le wikitty uniquement si le num��ro de version correspondant �� son num��ro de pair(son ordre dans la liste des owners), n'est pas sup��rieur a la version actuel du wikitty qu'il poss��de en base, evidement cel�� pour num��ro de version majeur egales. Si un pair disparait, cel�� pose probl��me si plus d'un wikitty service ont re��u la m��me version d'un wikitty en m��me temps, par exemple on aurait ce probl��me sur le sch��ma si M disparait, puisque s1 et s2 ont re��u une version 1 du wikitty. Si leurs versions se rencontrent on ne pourra pas d��cider laquelle va pr��valoir. M��me soucis si S3 disparait, on aurait un soucis sur la synchronisation entre S4 et S6, soucis pouvant ��tre r��solu en s'adressant �� un pair encore propri��taire soit S1 ici. Dans le cas ou un pair disparait, si un seul wikitty a synchroniser des wikitty dont celui qui a disparut ��tait le premier propri��taire, ce wikitty service deviens le premier owner symbooliquement. Si on synchronise un wikitty entre un wikitty service en haut de chaine(de owners), et un en bas de chaine par exemple de M �� S4, alors les owner intervenant entre ces deux wikitty service sont ignor�� et si on essayait d'envoyer une version 2 (de M) sur une version 1.2.3.5 (de S4) alors sur le wikitty service S4 la version sera maintenant 2.x et les "owners: M". Le seul soucis visible de cette solution pour le moment, est lors de la disparition d'un pair en d��but de chaine qui laisserais plusieurs pair fils au m��me niveau de owner, avec la m��me version majeur issu du owner pr��c��dent. Dans le cas ou le owner p��re est encore pr��sent, une synchronisation avec celui ci d��terminerait la version "vrai", en pratique, le premier arriv��. Pour ce genre de cas il faudrait un discriminant, rajouter quand on se rajoute en owner un entier qui serais ��quivalent au nombre de synchro concernant ce wikitty, donc incr��ment�� �� chaque fois. C'est une solution qui n��cessiterait de conserver trace du nombre de sync effectu��s sur un wikitty, assez lourd et pour un cas peut ��tre isol��. On ne peut pas se fier aux dates, puisque un wikitty service peut ��tre sur un serveur o�� la date est fauss��e. Dans ce cas l�� on pourrait peut ��tre envisager un algorithme de merge calculant les diff��rences, ou il faut du coup les consid��rer comme deux wikitty diff��rent, dans ce cas. Dans ce cas on se retrouve dans le m��me cas qu'avec une solution ou un wikitty service prendrait la version d'un wikitty si il ne le connait pas d��ja. Puisque en ce cas on a une collision si deux wikitty ont ��volu��s chacun de leur cot�� avec une version initiale identique.