Sp��cification Wikitty publication module de synchronisation =========================================================== :Authors: Mano��l Fortun Nouvelle approche sur le mod��le Rsync ------------------------------------- Cette nouvelle approche du module wikitty publication, bas�� sur Rsync, et plus un "simple" syst��me de commit/update/import/delete/relocate comme svn, est motiv�� par l'aspect plus g��n��raliste que cel�� apporte. Cette approche permet de syncrhoniser le contenu de n'importe quel wikitty service avec un autre, et donc de red��ployer simplement tout les wikittys que l'on souhaite d'un wikitty service �� un autre. La nature du wikitty service cible importe pas, on peut synchroniser un wikitty service sur un file system avec un wikitty service sur un serveur cajo, ou deux wikitty service sur des serveurs cajo, cette approche se veut plus universelle. Et pourra ��tre test�� justement entre deux wikitty service sur serveur. D��finitions ----------- Fichier -> Objets wikitty +++++++++++++++++++++++++ Un fichier est d��fini par un nom, une extention, un contenu et un chemin. dans wikitty publication les fichiers sont convertis en fonction de leurs type en objet wikitty. les fichiers sources sont convertit en WikittyPubText et les fichiers binaires(eg image, etc) en WikittyPubData. Les deux types d'objet ont les m��mes attribut: - Name: correspondant au nom du fichier - MimeType: crrespondant au type, qui donnera l'extension - Content: le contenu binaire pour pour les PubData et textuel pour les PubText Le mimetype donne l'extention par exemple pour un PubData si on a en mimetype "image/png" alors l'extension du fichier associ�� sera ".png". Dans le cas d'un PubText le mimetype donnera l'extension et le langage de la source par exemple si on a en mimetype "application/javascript" le langage est javascript et l'extension sera donc ".js". A ces objets wikitty on associe un wikittyLabel, c'est un objet qui peut contenir un ensemble de label diff��rent, un label par exemple "src.org.chorem.entities" sert ici pour contenir le chemin menant au fichier sur le file system. Un wikitty peut avoir un certain nombre de label, pour les wikittyPub cel�� indiquera qu'ils appartiennent �� plusieurs arborescences. Objets wikitty -> Fichier +++++++++++++++++++++++++ Lorsque l'on va enregistrer des wikitties en fichier en utilisant un wikitty service file system, on devra restaurer les fichiers en se servant des labels pour localiser sa place dans l'arborescence, du mimetype pour les extensions, etc. Dans ce cas le repo local des wikitty devra contenir toutes les informations du wikitty si l'on veux le renvoyer vers un autre wikitty service en se servant de l'application wikitty publication sync. Propri��t��s pour l'inversabilit�� fichier/wikitty +++++++++++++++++++++++++++++++++++++++++++++++ Tout objet wikitty dispose d'une version qui est modifi��e par le wikitty service �� chaque modification de l'objet wikitty, les wikittypub donc aussi. Cette information de la version sera stock��e dans un fichier de propri��t�� dans un dossier cach�� ".wp/" afin que l'on garde tr��ce des versions des objets que l'on aura transform�� en fichier, cel�� pour une synchronisation ult��rieure avec un autre wikitty service. On conservera trace ausi dans ce m��me fichier de propri��t�� du label courant, permettant de ne pas faire d'op��ration "complexes" et p��nible sur les noms de fichier afin de retrouver le label de travail. Conserver trace du label actuel �� l'avantage de n'avoir pas besoin de rechercher dans l'arborescence la premi��re occurence du fichier de propri��t�� pour pouvoir reconstituer le label complet. On distinguera deux fichiers de propri��t��s pour les informations un qui conservera les id des wikitty li�� �� leur nom de fichier. Et un autre fichiers de propri��t�� qui conservera un checksum, la version et les id aussi. On conserve les id dans un premier fichier puisque cel�� permet simplement de r��cup��rer l'ensemble des id et leurs noms de fichier li�� sans avoir besoin de faire le tri parmis toutes les propri��t��s enregistr��es. On converse l'id aussi dans un autre fichier de propri��t��, �� d��faut d'avoir un system de type bidimap pour les prori��t��s, cel�� permet de r��cup��rer l'id d'un wikitty �� partir de son nom de fichier, et inversement du nom de fichier �� l'id. La propri��t�� checksum sera utilis��e pour enregistrer la somme de controle de l'objet lors de son enregistrement, pour plus tard, savoir si celui ci �� ��t�� modifi�� depuis lors. Exemple pour un contenu de file system: +racine |script.js |scripttut.js |image.png |+.wp ||id.properties ||meta.properties |+directory2 ||script3.js ||+.wp |||meta.properties |||id.properties ||+directory3 |||truc.js |||+.wp ||||meta.properties ||||id.properties |+directory22 ||machin.png ||+.wp |||versions.properties |||id.properties Exemples de fichiers de propri��t��s: meta.properties: script.js.version=num��roVersion7 scripttut.js.version=num��roVersion image.png.version=num��roVersion current.label=racine script.js.checksum= checksum scripttut.js.checksum= checksum image.png.checksum= checksum id.image.png=uubdazudba id.scripttut.js=11daz5facz id.script.js=jbdub1dza8 id.properties: uubdazudba=image.png 11daz5facz=scripttut.js jbdub1dza8=script.js Fonctionnalit�� -------------- Sync ++++ D��finitions *********** La fonctionnalit�� CP permet de transf��rer l'ensemble des wikittys cibl��s par l'uri, d'un service wikitty �� un autre. Son fonctionnement doit ��tre similaire �� la commande linux "rsync". On reprendra donc quelques options comme: - Recursion pour savoir si l'on s'occupe des sous labels du label cibl��. - Update, qui permettra de mettre �� jour ce qui est pr��sent et ant��rieur sur la cible et d'y envoyer les nouveaux wikitty. Par d��faut cette option sera active, et sera desactiv��e lorsque les autres option (delete ou existing) seront choisis. - Existing qui est un update mais sans l'envois des nouveaux fichiers, on envois juste ce qui �� ��t�� mis �� jour et qui existe sur le wikitty service cible. - Delete pour supprimer dans le wikitty cible, ce qui n'existe plus dans le wikitty origine. La suppression n'est pas une vraie suppression elle se contente de supprimer le label cibl�� du wikitty. En fonction des uris des wikitty services cibl�� par la fonction, une impl��mentation diff��rente de service wikitty sera instanci��, en fonction des protocoles (file, hessian ou cajo). Prototype commande ****************** ''wp sync [--norecursion] [--delete|--existing] [URI orgirine] [URI cible]'' Avec URI sous forme: - file:///truc/machin/#label - hessian://www.adresse.com:8827/etc/etc#label - cajo://www.adresse.com:8827/etc/etc#label Evidement le path pour le protocole File indiquant le r��pertoire o�� aller chercher/mettre les wikitties. Les labels de l'uri cible et local peuvent ��tre diff��rent, et pendant ils seront conserv��, c'est �� dire que des wikitties de la cible si ils ont besoin de se mettre �� jour, leurs labels seront conserv��s. Dans le cas de wikitty qui n'existe pas dans la cible, on remplacera le label origine qui �� permis de trouver ces wikitties et le remplacer par le label cible, les autres labels du wikitty seront transmit. Wikitty Service File System --------------------------- Un tel service devra fournir les m��thodes suivantes les m��thodes de sauvegarde des wikitty, de restauration, ainsi qu'un certain nombre de fonctionnalit��s concernant les recherches de wikitty. Le wikitty service sur file system prendra en charge les recherches sur crit��ria de fa��on compl��te. A chaque recherche sur le wikitty service file system, il faudra indexer les nouveaux wikitty, enlever les property des fichiers/wikitty supprim��, incr��menter la version mineur si il y a eut des modifications depuis la derni��re indexation.