Author: mfortun Date: 2011-04-29 17:58:21 +0200 (Fri, 29 Apr 2011) New Revision: 850 Url: http://nuiton.org/repositories/revision/wikitty/850 Log: * cosmetic changes Modified: trunk/wikitty-publication/src/site/rst/sync.rst Modified: trunk/wikitty-publication/src/site/rst/sync.rst =================================================================== --- trunk/wikitty-publication/src/site/rst/sync.rst 2011-04-29 13:25:31 UTC (rev 849) +++ trunk/wikitty-publication/src/site/rst/sync.rst 2011-04-29 15:58:21 UTC (rev 850) @@ -10,17 +10,17 @@ ------------------------------------- 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. +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. +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. +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 @@ -38,15 +38,16 @@ - 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 + - 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". +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 @@ -77,22 +78,22 @@ 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 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 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. +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é @@ -149,14 +150,14 @@ --------------------------- 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. +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. +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. Fonctionnalités @@ -167,28 +168,30 @@ 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". +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. + sera active, et sera desactivée lorsque les autres options (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. + 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. +La suppression n'est pas une vraie suppression elle se contente de supprimer le +label ciblé du wikitty, sauf le cas d'un wikitty publication file system où il +s'agira de la suppresion du fichier et des informations 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). +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 @@ -209,8 +212,8 @@ 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. +origine qui à permis de trouver ces wikitties et le remplacer par le label +cible, les autres labels du wikitty seront transmit. Commit/update @@ -219,17 +222,20 @@ Définitions *********** -On va conserver des fonctionnalités de type commit/update, l'utilisation de ces fonctions -nécessitera un "repository" wikitty publication file system existant dans l'arborescence. -Le but de ces fonctionnalités est de faire des Sync avec un autre wikitty service sans -avoir besoin de redonner sont adresse explicitement à chaque fois avec la commande sync. +On va conserver des fonctionnalités de type commit/update, l'utilisation de ces +fonctions nécessitera un "repository" wikitty publication file system existant +dans l'arborescence. Le but de ces fonctionnalités est de faire des Sync avec un +autre wikitty service sans avoir besoin de redonner sont adresse explicitement à +chaque fois avec la commande sync. -Un commit sera équivalent à un sync du "reposistory" local vers un autre wikitty service. -Un update sera équivalent à un sync d'un autre wikitty service vers le repositotory local. +Un commit sera équivalent à un sync du "reposistory" local vers un autre wikitty +service. Un update sera équivalent à un sync d'un autre wikitty service vers le +repositotory local. -Pour ce faire dans le dossier racine qui contient l'arborescence des wikitty sous forme de fichier -on enregistrera dans un dossier ".wp" un fichier "ws.properties" qui contiendra l'adresse -du dernier wikitty service utilisé pour faire un sync. +Pour ce faire dans le dossier racine qui contient l'arborescence des wikitty +sous forme de fichier on enregistrera dans un dossier ".wp" un fichier +"ws.properties" qui contiendra l'adresse du dernier wikitty service utilisé pour +faire un sync. Prototype commande @@ -237,7 +243,8 @@ ''wp [update|commit] [--norecursion] [--delete|--existing] [label] [URI file]'' -L'URI file est optionnelle, si pas précisée on va commit/update le dossier local. +L'URI file est optionnelle, si pas précisée on va commit/update le dossier +courrant. -Pour le commit update, on doit forcément préciser le label pour le wikitty service cible, -celà pour permettre de commit ou update au bon endroit. +Pour le commit update, on doit forcément préciser le label pour le wikitty +service cible, celà pour permettre de commit ou update au bon endroit.