ParaboleDuLivre

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur ParableOfTheBook

Dans le VraiMonde, quand deux personnes parviennent au même livre sur une table, le saisissant en même temps, les conflits sont résolus à travers une rétroaction -- pas par le verrouillage et la synchronisation. Imaginez qu'elles tirent toutes les deux sur le livre, une personne le laissera aller en premier, permettant ainsi à l'autre de le garder. Les problèmes se posent bien sûr quand les deux veulent le livre en même temps, mais la communication résoud normalement cela (entre adultes agissant de BonneFoi ; les interfaces pour les enfants ou les attaquants peuvent avoir différentes exigences). Par exemple, "Oh désolée, pourrais-je avoir le livre pour une minute. Je voulais juste regarder quelque chose rapidement". "Bien sûr, pas de problème."

Dans les environnements en ligne, il est souvent suffisant d'indiquer que les objets en contention sont en contention. Un CanalDeCommunication additionnel, secondaire, comme une session de messagerie instantanée, devrait fournir toute la RésolutionDeConflit requise. Ceci résultera en un protocole plus simple et une InterfaceUtilisateur plus simple.

Quelques-uns pourraient répondre qu'il est mieux de simplement empêcher l'interaction avec un objet une fois qu'il est utilisé par quelqu'un d'autre. Notez que cela exigerait une interface très ennuyeuse, parce qu'on pourrait commencer à n'utiliser un objet avant qu'on ne reçoive la notification de conflit. Ce qui veut dire, que parce que les deux clients ont envoyé des notifications, est-ce que les deux clients devraient verrouiller l'objet (résultant en un objet mort) ? Est-ce que les deux devraient le laisser tomber (abandon unilatéral des actions des deux utilisateurs) ?

Une meilleure démarche serait de démontrer cela en premier, l'objet que vous contrôlez est disputé, et deuxièmement, le statut en corus de l'objet à l'autre personne (disons, où il en est actuellement).

Un autre cas est quand un utilisateur saisit un objet avant qu'il ne reçoive une notification qu'il a été détruit par le client étranger. Dans ce cas, il est mieux de restaurer l'objet, même si le premier utilisateur a l'intention de le détruire tout aussi bien.

Notez que le seul moyen pour que les gens puissent saisir en même temps le livre dans le vrai monde est s'ils ne prêtent pas attention l'un à l'autre. Avec le groupware, souvent le cas est qu'ils ne peuvent même pas se voir l'un l'autre. Par conséquent, on démontrerait au client étranger ce que le client local est en train de faire, disons en notifiant l'autre client des actions en cours. Ainsi, deux utilisateurs peuvent "sortir de la voie de l'autre".

Un avertissement néanmoins. A la différence d'un livre, si les utilisateurs peuvent tous deux simultanément changer l'état d'un objet indépendamment de l'autre, alors l'objet n'est pas analogue à un livre. Dans ce cas, vous pouvez soit forcer les dépendances, permettre la désynchronisation ou verrouiller l'objet.

Une bonne résolution est de permettre constructivement la désynchronisation en dupliquant par transparence la ressource une fois que la désynchronisation a été détectée. Ce qui veut dire, donner à chaque utilisateur son propre livre. De cette façon, personne ne perd de donnée et leurs actions ne sont pas interrompues.

DossierDesignInterface?

Simplement deux mois plus tôt, je me suis blessé l'esprit pour sortir cette idée, elle était publiée. Ne va seulement vous montrer combien de temps une bonne recherche de documentation peut vous faire gagner. :( -- SunirShah

Références

Chen, D. and Sun, C. (1999). A distributed algorithm for graphic objects replication in real-time group editors. In Proceedings of the international ACM SIGGROUP conference on Supporting group work, Phoenix, Arizona.

Voir aussi SolutionCommunauté, SolutionTechnologie

LangueFrançaise PageTranslation ParableOfTheBook

ParaboleDuLivre

Références

Discussion