Historique : Futur - Exclusion mutuelle

Edition simultanée

Sommaire

(pfiou vivement la generation automatique de sommaire  ;))

Problème

Pour le moment, le fait d'enregistrer fait une sauvegarde de la page avec la date courante, ce qui a pour effet d'outrepasser toutes les version précédentes.

Le problème est que lorsque l'on entre en édition, on ne peut pas savoir si la page est déjà en cours d'édition. Il se peut alors que les modifications que l'on fait ne soient pas prises en compte si l'on sauvegarde avant la personne étant en train d'éditer.

[<< Retour au menu]

Propositions de solutions

Modèle Lock-Modify-Unlock

Ce problème pourrait être contourné en réservant l'édition à une seule session, interdisant ainsi l'édition aux autres personnes tant que cette édition n'est pas terminée.

Il va alors falloir définir un temps maximum d'édition pour éviter qu'une personne puisse bloquer définitivement une page.

Je ne sais pas si j'ai bien suivi les news, mais où est en l'exclusion mutuelle ? Toujours absente ? C'est vrai que ça serait bien de s'en occuper pasque c'est un peu critique de pouvoir faire des modifs concurrentes, ça empêche d'utiliser ChuWiki en prod :)

Proposition :

Voilà pour la conception :-) @ toi Vincent.

\-- Baptiste

Merci Baptiste mais nous avions déjà fait cette phase :D Mais c'est très gentil à toi d'avoir écris quelque chose là dessus.

Première chose, l'exclusion mutuelle est dans la page Futur, il ne faut donc pas l'attendre pour la 1.0.

Parlons maintenant de ce que tu as évoqué. Le problème est plus fin. À savoir que des scripts PHP peuvent s'exécuter en parallèle, il faut donc mettre en place une vrai exclusion au moment du test du fichier et de sa création. Nous avons fait quelques tests avec Darken en suivant quelques pistes, ils ne sont que moyennement concluant car la fonction que nous souhaitons n'est que dans une version très récente de PHP.

Pour le JS Timer, c'est une bonne idée, mais je ne sais pas le faire pour le moment, il faudra se pencher là dessus. :)

Pour les 30 minutes, il faudrait en discuter plus longuement. Je ne veux pas non plus qu'un gars se pointe et lance une édition sur toutes les pages pour bloquer le site 30 minutes. Je pensais personnelement à une durée plus courte 5/10 minutes mais il serait possible de mettre le compteur à 0 en prévisualisant.

\-- Vincent

[<< Retour au menu]

Modèle Copy-Modify-Merge

Bonsoir messieurs, j'ai moi aussi été confronté à ce problème (décidement) lors de mon codage (... bla bla, ma vie, mon oeuvre, etc ...) alors ma fausse astuce mais qui fonctionne vraiment consiste à utiliser un champ caché (dans le formulaire d'édition) qui contient la date de dernière modification de la page, et au moment de la sauvegarde, on compare la date envoyée par formulaire et celle (réelle cette fois) de la page/fichier ; si elles sont différentes, on averti l'utilisateur qu'il faut qu'il copie ses modifs et rocommence l'édition. (valà, j'espère avoir été claire.. si quelqu'un veut en savoir plus, god@@@doomy...org, je suis pressé.. bye) \-- AnonymousCoward

Ah et pour le js, je le déconseille.. certains navigateur (encore utilisés) ne le supporte pas.. Je ne suis pas sûr par exemple que le fureteur pour PALM, Lynx, Links, MiniMoz (basé sur Gecko, roxor), et d'autres suppportent le js. \-- idem au dessus

C'est toujours quand on est pressés qu'on a le plus d'idées, pourquoi ne pas se baser sur ma solution (cf: plus haut) et afficher un diff (cf: mon post sur le Futur et le moteur de diffs) entre ce que l'utilisateur poste et la version actuelle de la page.

Moi je trouve cette solution (celle de AnonymousCoward) très élégante et simple (pas besoin de js, de session php ou d'autre bazard). J'imaginais aussi de proposer directement l'édition de la nouvelle version mais de présenter les modifs que l'utilisateur voulait enregistrer pour qu'il nai qu'à copier coller ses modifs dans la nouvelle version.

je ne sais pas ce qu'en pense le sieur vincent, s'il a déjà pris une décision à ce sujet...

je suis pas contre me faire le boulot sur cette partie...


--Bertrand

Bertrand, je commence à avoir un peu honte. Alors que mon travail me prend tout mon temps, c'est principalement toi qui fait évoluer ChuWiki ces derniers temps, et pour cela, sois-en mille fois remercié, de la part de tous les utilisateurs actuels ou futurs de ChuWiki.

Pour revenir au sujet, j'avous ne pas encore avoir trop réfléchi à la question. Cela me semble encore vraiment problématique, notamment de l'expérience de l'utilisation de MediaWiki en concurrence.


-- Vincent

Ne t'inquiète pas, je profite d'une période où mes missions ne sont pas très techniques pour provoquer un manque et le soir quand je rentre, je me gave :o) Entre un plugin DotClear par-ci, un petit algo par là, et maintenant Chuwiki (qui est vraiment un bel objet, définitivement), ça me permet de tenir et d'avoir ma dose :o)

Sinon, pour revenir au sujet moi aussi (c'est vrai quoi on va pitet bien arrêter de se lancer des fleurs, ça devient gênant), je ne connais pas spécialement MediaWiki, et je n'ai pas trouvé une liste de feature indiquant s'il gère l'édition concurente et si oui comment. il fait quoi ce MédiaWiki ?


--Bertrand

Et bien il est capable de détecter si une édition concurrente a eu lieu, sûrement par un mécanisme comme décrit plus haut stockant la date de dernière modif et la comparant avec l'actuelle au moment de la sauvegarde.

Le problème est que lors de cette modification, il n'a rien trouvé de mieux que de lancer l'édition de la version concurrente, ce qui est fort désagréable puisque tous les changements que l'on vient d'effectuer sont perdus.

Généralement le bouton Précédent des navigateurs permet de récupérer son travail et de le réenregistrer, mais sans aucune considération pour la version concurrente, écrasant ainsi tout le travail des autres, un peu comme ChuWiki à l'heure actuelle.

Il faudrait donc générer une différence entre les 2 versions, ce qui permettrait de faire un merge lorsque c'est possible. J'avais trouvé un exemple plutôt intéressant mais il faudrait tester un peu plus cet algorithme afin de voir ce qu'il vaut en terme de fiabilité et de performance lorsque l'on travaille sur de gros fichiers (ce qui est tout de même le but d'un wiki).


-- Vincent

Je vois...et le merge tu l'imagines automatique ou bien c'est à l'utilisateur à partir du diff de faire sa cuisine pour obtenir une version correcte ? en fait, en écrivant (comme quoi...), je me rends compte que le merge automatique est une ineptie quand il s'agit de reformuler un phrase, de réorganiser une page, etc.

une question que je me pose est aussi la meilleure façon de présenter à l'écran la version de l'utilisateur, la version sauvegardée entre-temps et un textarea d'édition...ça risque de faire beaucoup de choses pour un pitit écran...


--Bertrand

Bonjour !

Où en somme nous pour l'exclusion mutuelle ? Car j'ai l'impression qu'il y a même des cas où on se retrouve avec une page vide lors de conflits.


--Geob

C'est toujours en attente... Par contre, je n'ai jamais vu le comportement dont tu parles.


-- Vincent

va falloir que je dégage un peu de temps pour m'y mettre à cette exclusion mutuelle !!


-- Bertrand

[<< Retour au menu]

Références de solutions existantes

On peut trouver dans le livre de subversion un argumentaire qui va dans le sens de preferer la solution proposee par AnonymousCoward (Copy-Modify-Merge) plutot qu'un systeme de lock (Lock-Modify-Unlock).

C'est aussi le choix qu'a fait pmwiki (lui aussi ecrit en php a base de fichiers textes, donc peut-etre qu'il y a a moyen de recuperer des bouts de code).

Voir la page Futur - Visualiser les différences entre 2 versions#liens pour une liste de codes sources existants.


-- 1728 [18 avril 2006 et 24 juin 2006]

[<< Retour au menu]

Propositions de solutions intermédiaires

le modele cvs/subversion/pmwiki semble ideal mais demande pas mal de boulot :

N.B. ce que fait pmwiki est pas mal dans la mesure ou la 2e personne qui sauvegarde n'est pas obligee de resoudre le conflit de versions immediatement, elle peut laisser une 3e personne le faire plus tard sans perdre d'information.

Dans l'attente, on peut imaginer des solutions plus ou moins simples qui permettent de faire avec (ou plutot sans).

(N.B. la page Changements récents actuelle liste les pages modifiees par date de derniere modification, mais ne permet pas de voir si une page a ete modifiee plusieurs fois, elle correspond plus a "Pages recemment modifiees" qu'a "Changements récents").


-- 1728 [2 mai 2006]

À propos de la solution de AnonymousCoward je pense qu'il suffirait de coupler cela à une mise en page différente de la page Historique. Chaque version aurait ainsi deux dates : celle de son enregistrement et celle de sa version de départ (champ caché). Si on conserve bien ces deux infos, il est possible de mettre en page l'Historique d'une manière parlante.

Je m'explique : jusqu'à la version 3, tout va bien, et l'Historique est présenté en colonne, comme actuellement. Supposons maintenant que la version 3 ait donné la version 4a ainsi que la version 4b. Alors on met 4a et 4b côte à côte dans l'Historique. Ensuite, si la version 5 est construite à partir de la version 4b, on dispose son lien sous celui de 4b, donc décalé par rapport à ceux des versions 1, 2, 3, 4a. Du coup, on voit du premier coup d'oeil quelle version a été écrasée (en l'occurrence la version 4a).

Je ne sais pas si c'est clair ?


-- Cyprien. [10 mars 2007]

[<< Retour au menu]