Fw: Spécifications sync de wikitty pub
----- Message Transféré ----- Date: Fri, 1 Apr 2011 17:58:43 +0200 De: Manoël <manoel.fortun@gmail.com> Bonjour, Voilà mes spécifications pour les fonctionnalités de sync de wikitty pub. Il y aura sûrement des choses à rediscuter ou préciser. Manoël. _______________________________________________ Lutins mailing list Lutins@list.codelutin.com http://list.codelutin.com/cgi-bin/mailman/listinfo/lutins
On Fri, 1 Apr 2011 19:35:55 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
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
Il te manque quelque chose dans ton analyse, comment sait tu qu'un fichier sera un PubText ou un PubData ? Le plus simple est de dire que tout ce qui est de type text/xxxx sera un PubText et tout le reste du PubData. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
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
Il te manque quelque chose dans ton analyse, comment sait tu qu'un fichier sera un PubText ou un PubData ?
Le plus simple est de dire que tout ce qui est de type text/xxxx sera un PubText et tout le reste du PubData.
Une table de correspondance entre mimetype et extension et pubtext/pubdata finalement ?
On Fri, 1 Apr 2011 19:35:55 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Exemple pour un contenu de file system:
Il manque les repertoires .wp et les fichiers qu'ils contiennent
+racine |+wp || ws.properties # l'adresse du WikittyService || versions.properties # le nom des fichiers avec leur version |script.js |scripttut.js |image.png |+directory2 ||+wp ||| versions.properties # le nom des fichiers avec leur version ||script3.js ||+directory3 |||+wp |||| versions.properties # le nom des fichiers avec leur version |||truc.js |+directory22 ||+wp ||| versions.properties # le nom des fichiers avec leur version ||machin.png
Fichier de propriétés correspondant:
script=numéroVersion
Peut-etre mettre aussi l'extension ? ...
label= racine.directory2, racine.directory22
Pour moi, il n'y a aucun intérêt à conserver label, on le retrouve avec les répertoires -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
2011/4/1 Benjamin POUSSIN <poussin@codelutin.com>
On Fri, 1 Apr 2011 19:35:55 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Exemple pour un contenu de file system:
Il manque les repertoires .wp et les fichiers qu'ils contiennent
Effectivement j'avais oublié les dossiers .wp
+racine |+wp || ws.properties # l'adresse du WikittyService || versions.properties # le nom des fichiers avec leur version |script.js |scripttut.js |image.png |+directory2 ||+wp ||| versions.properties # le nom des fichiers avec leur version ||script3.js ||+directory3 |||+wp |||| versions.properties # le nom des fichiers avec leur version |||truc.js |+directory22 ||+wp ||| versions.properties # le nom des fichiers avec leur version ||machin.png
Fichier de propriétés correspondant:
script=numéroVersion
Peut-etre mettre aussi l'extension ?
Pour moi l'extension peut être retrouvé rapidement avec une table de correspondance extension/mimetype, mais ça peut être pratique de la mettre quand même dans le fichier de properties, ça sera pas une information si lourde et si ça peut faire gagner du temps c'est bien.
...
label= racine.directory2, racine.directory22
Pour moi, il n'y a aucun intérêt à conserver label, on le retrouve avec les répertoires
Disons que je pense que les conserver peut permettre de gagner du temps pour les comparaisons d'architecture pour un commit, update, on retrouvera presque instantanément les dossiers ajoutés, ceux supprimé etc. Dans un premier temps mettre les labels en plus dans le fichier de properties puis ensuite les enlever si finalement ça ne sert pas, c'est plus facile de partir avec le plus d'infos au départ que devoir en rajouter après, de mon point de vue.
On Mon, 4 Apr 2011 10:12:58 +0200 Manoël <manoel.fortun@gmail.com> wrote:
Peut-etre mettre aussi l'extension ?
Pour moi l'extension peut être retrouvé rapidement avec une table de correspondance extension/mimetype, mais ça peut être pratique de la mettre quand même dans le fichier de properties, ça sera pas une information si lourde et si ça peut faire gagner du temps c'est bien.
pour retrouver rapidement le fichier, avoir l'extension dans le fichier properties est clairement un plus, voir obligatoire si on veut avoir pour l'unicité: WikiPubXXX.name + WikiPubXXX.mimetype Car sinon on ne pourra pas avoir une image et un fichier html avec le meme nom ce qui pourrait etre pratique. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Fri, 1 Apr 2011 19:35:55 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
''wp import [--recursion (true|false)] [url du WikittyService] [directory]''
Ce n'est pas un peu embetant de devoir mettre recursion true/false :( Je pense que le plus simple serait plutot une option --norecursion et par defaut on est en recursion. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
2011/4/1 Benjamin POUSSIN <poussin@codelutin.com>
On Fri, 1 Apr 2011 19:35:55 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
''wp import [--recursion (true|false)] [url du WikittyService] [directory]''
Ce n'est pas un peu embetant de devoir mettre recursion true/false :(
Je pense que le plus simple serait plutot une option --norecursion et par defaut on est en recursion.
Je suis d'accord, je l'avais laissé puisque dans le rst c'était présenté ainsi. Mais oui c'est plus pénible qu'autre chose, donc oui changer pour le --norecursion.
J'approuve les remarques de Ben, surtout la récursion et effectivement, je me demande si y'a pas une vrai différence entre répertoire et label et d'après les cas d'utilisation que je vois, j'ai l'impression que les répertoires suffisent. Tout comme dans svn on peut très bien checkouter une sous-partie de l'arborescence. L'idée des label est qu'on pourrait checkouter seulement une partie des données seulement ? genre un label "truc" mais les wikitty labellisés truc se trouvent un peu partout dans l'arbo et on ne prend que ceux-là ? Je ne vois pas de différence entre import et commit. Comme j'ai l'ai dit, vu l'aspect décentralié (relocate toussa), il faut plutôt coller aux commandes des DVCS. D'ailleurs import, quand j'ai lu ce que ça faisait j'avais pensé à import dans l'autre sens, "import" ne veut rien dire, la question c'est de savoir qui importe/exporte. Un terme tel que "push" serait plus adapté. Pour les commandes courantes, je reprendrais la liste ici (init/clone/pull/push/checkout/update/commit etc.) : http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_C... Il manque le revert, indispensable :) Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter à la main derrière (bonne idée) ? Côté Wikitty Service, vu qu'on est en HTTP, on pourrait utiliser ces mots comme verbes HTTP voire coller avec REST (on attend toujours une présentation en réunion dev ;)). Sur la contrainte au commit (version locale au moins égale à celle du WS), pourquoi pas (ça oblige le mec à faire un update avant de commiter et donc à voir les conflits), mais SVN, lui, fait le merge. Sinon, pinaillage mais "wp" je trouve ça vraiment trop nul comme nom. Déjà ça évoque WordPress, WikiPédia ou une commande native. Je préfèrerai "wyp" ou "wypub". -- Brendan Le Ny Code Lutin
2011/4/2 Brendan Le Ny <bleny@codelutin.com>
J'approuve les remarques de Ben, surtout la récursion et effectivement, je me demande si y'a pas une vrai différence entre répertoire et label et d'après les cas d'utilisation que je vois, j'ai l'impression que les répertoires suffisent. Tout comme dans svn on peut très bien checkouter une sous-partie de l'arborescence. L'idée des label est qu'on pourrait checkouter seulement une partie des données seulement ? genre un label "truc" mais les wikitty labellisés truc se trouvent un peu partout dans l'arbo et on ne prend que ceux-là ?
D'après ce que j'ai compris, les labels sont les dossiers finalement, leur nom permet de les situés dans l'arborescence, et c'est grâce donc à ces labels que l'on peut replacer les fichiers dans l'arborescence. Et ça explique pourquoi on fait la récursion sur les labels quand on veut checkout, commit, etc. Et pour checkout un label "truc" qui placerais des fichiers un peu partout, c'est ce que je pensais au départ mais on m'a dit que justement non, on a correspondance entre label et dossier finalement.
Je ne vois pas de différence entre import et commit. Comme j'ai l'ai dit, vu l'aspect décentralié (relocate toussa), il faut plutôt coller aux commandes des DVCS. D'ailleurs import, quand j'ai lu ce que ça faisait j'avais pensé à import dans l'autre sens, "import" ne veut rien dire, la question c'est de savoir qui importe/exporte. Un terme tel que "push" serait plus adapté. Pour les commandes courantes, je reprendrais la liste ici (init/clone/pull/push/checkout/update/commit etc.) :
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_C...
Il manque le revert, indispensable :)
Le revert implique que on ait dans l'arborescence dans les fichiers caché une sauvegarde du contenu précédent, je veux bien, mais es ce que je vais pas réinventer la roue en refaisant un gestionnaire de version finalement ? En moins bien.
Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter à la main derrière (bonne idée) ?
A priori le modèle de fonctionnement voulait que le add soit par défaut dans le commit, on add dans le wikittyservice tout ce qui à été rajouté dans le projet sans se poser de question. Le modèle de delete "commit" tout seul d'après le modèle. Le fait de pas commit directement impliquerait de mettre un "marqueur" dans le fichier de propriété pour qu'au commit le delete soit pris en compte, ça change pas mal de chose pour moi, à voir avec Benjamin comment il voit ça, et le modèle de fonctionnement qu'il souhaite. Côté Wikitty Service, vu qu'on est en HTTP, on pourrait utiliser ces mots
comme verbes HTTP voire coller avec REST (on attend toujours une présentation en réunion dev ;)).
Là, je passe.
Sur la contrainte au commit (version locale au moins égale à celle du WS), pourquoi pas (ça oblige le mec à faire un update avant de commiter et donc à voir les conflits), mais SVN, lui, fait le merge.
Le modèle de merge qu'on m'a proposé c'est de faire comme cvs, à coup de chevron pour noter les différences entre version locale et distante, faire un "vrai" système de merge je m'éloignerais un peu du sujet de base non ? Je passerais de wikittypublication à un gestionnaire de version en java sur wikitty.
Sinon, pinaillage mais "wp" je trouve ça vraiment trop nul comme nom. Déjà ça évoque WordPress, WikiPédia ou une commande native. Je préfèrerai "wyp" ou "wypub".
J'ai pas d'avis sur la question.
On Mon, 4 Apr 2011 10:45:19 +0200 Manoël <manoel.fortun@gmail.com> wrote:
2011/4/2 Brendan Le Ny <bleny@codelutin.com> ...
Il manque le revert, indispensable :)
Un simple appel sur le WikittyService en demandant la restoration de l'objet avec une version donnée suffira (lorsque cette fonction sera implantée dans wikitty :)) ...
Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter à la main derrière (bonne idée) ?
Non, ca commit tout seul, sinon il faut retenir tout un tas d'information en local qui complexifie tout. L'idée ici (pour l'instant) n'est pas de remplacer ou réécire une gestion de version de source comme git, svn, ou autre. Mais juste d'avoir un moyen de récupérer un ensemble d'objet wikitty sur le filesystem local pour pouvoir facilement les modifier avec les outils de dev traditionnel puis repousser ces fichiers en objet wikitty dans un WikittyService. Si l'on veut une vrai gestion de version, il faut, une fois les objets récupérer en fichier les mettre dans un SVN ou autre. SVN ne fait pas le delete ou le add avec un commit autmatique car il gere un numero de revision unique pour un ensemble de modification avec un message de commit. Ce qui n'est absolument pas notre cas, nous n'avons pas de message de commit et encore moins un numero unique (equivalent a une transaction) pour un ensemble de modification. Chaque objet a son propre numero de version. Donc que tu commit juste apres la commande remove ou que tu doives faire le commit a la main plus tard au final on a exactement le meme resultat. Donc le mieux est de faire au plus simple "le remove, commit" (ce qui supprime simplement un tag de l'objet) ...
Sur la contrainte au commit (version locale au moins égale à celle du WS), pourquoi pas (ça oblige le mec à faire un update avant de commiter et donc à voir les conflits), mais SVN, lui, fait le merge.
Il fait le merge lorsque ce ne sont pas les memes lignes qui sont modifier, sinon il fait des trucs super compliqué que j'aime pas :(. Dans un premier temps il faut faire au plus simple et implanter des mécanisme plus complexe par la suite (en utilisant des libs existantes) Donc en gros avec une methode merge (fichier qui vient du serveur, fichier local):Status qui par exemple renome le local avec son numero de version+bak et sauve celui du serveur avec le nom local Par contre le status qui ressort serait ce qui a ete fait: - N: nouveau - U: update - B: backup - R: replace ... comme ce que ressort un svn update Puis par la suite, on pourra modifier seulement l'implantation de cette methode pour faire des choses plus intelligentes. La seul question qui reste en suspend est comment savoir que l'objet local a ete modifié par rapport a la version du serveur ? On va peut-etre être obligé d'avoir dans le réperoire .wp (ou autre ;)) un répertoire orig qui contient le fichier dans sa version serveur. Du coup, on peut savoir facilement si le fichier local a ete modifier (différence entre le fichier local et le fichier dans orig) Idem pour le coté serveur grace à la version qui a été modifié. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Mon, 4 Apr 2011 16:58:06 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Mon, 4 Apr 2011 10:45:19 +0200 Manoël <manoel.fortun@gmail.com> wrote:
...
Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter à la main derrière (bonne idée) ?
Non, ca commit tout seul, sinon il faut retenir tout un tas d'information en local qui complexifie tout.
L'idée ici (pour l'instant) n'est pas de remplacer ou réécire une gestion de version de source comme git, svn, ou autre. Mais juste d'avoir un moyen de récupérer un ensemble d'objet wikitty sur le filesystem local pour pouvoir facilement les modifier avec les outils de dev traditionnel puis repousser ces fichiers en objet wikitty dans un WikittyService.
Si l'on veut une vrai gestion de version, il faut, une fois les objets récupérer en fichier les mettre dans un SVN ou autre.
Moi j'ai l'impression qu'on s'en approche quand meme enormement... Il serait peut etre interessant de voir comment SVN ou GIT fonctionne "mecaniquement" et en retirer des indications sur nos besoins.
SVN ne fait pas le delete ou le add avec un commit autmatique car il gere un numero de revision unique pour un ensemble de modification avec un message de commit.
Ce qui n'est absolument pas notre cas, nous n'avons pas de message de commit et encore moins un numero unique (equivalent a une transaction) pour un ensemble de modification. Chaque objet a son propre numero de version.
Donc que tu commit juste apres la commande remove ou que tu doives faire le commit a la main plus tard au final on a exactement le meme resultat. Donc le mieux est de faire au plus simple "le remove, commit" (ce qui supprime simplement un tag de l'objet)
...
Sur la contrainte au commit (version locale au moins égale à celle du WS), pourquoi pas (ça oblige le mec à faire un update avant de commiter et donc à voir les conflits), mais SVN, lui, fait le merge.
Il fait le merge lorsque ce ne sont pas les memes lignes qui sont modifier, sinon il fait des trucs super compliqué que j'aime pas :(. Dans un premier temps il faut faire au plus simple et implanter des mécanisme plus complexe par la suite (en utilisant des libs existantes)
Donc en gros avec une methode merge (fichier qui vient du serveur, fichier local):Status qui par exemple renome le local avec son numero de version+bak et sauve celui du serveur avec le nom local
Par contre le status qui ressort serait ce qui a ete fait: - N: nouveau - U: update - B: backup - R: replace ...
comme ce que ressort un svn update
Puis par la suite, on pourra modifier seulement l'implantation de cette methode pour faire des choses plus intelligentes.
La seul question qui reste en suspend est comment savoir que l'objet local a ete modifié par rapport a la version du serveur ? On va peut-etre être obligé d'avoir dans le réperoire .wp (ou autre ;)) un répertoire orig qui contient le fichier dans sa version serveur.
Du coup, on peut savoir facilement si le fichier local a ete modifier (différence entre le fichier local et le fichier dans orig)
Idem pour le coté serveur grace à la version qui a été modifié.
Dans le meme ordre d'idée que précédement, on peut sans doute avoir une reponse dans le fonctionnement de SVN ou Git (avec un option sur git ou autre decentralisé je pense ) -- Yannick
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Manoël -
Yannick Martel