Fonctionnalités de base dans un collecticiel d’édition coopérative

L’éditeur est le composant autour duquel s’articule la coopération. Il doit inclure en plus des fonctionnalités classiques d’un éditeur mono-usager, les mécanismes permettant la communication entre les usagers et le partage du document. Ce partage implique en particulier le contrôle des accès aux données partagées.

• Granularité des données partagées

Un document peut être considéré comme un bloc monolithique ou comme un ensemble de parties plus petites. Dans ce dernier cas deux unités sont à considérer. D’une part l’unité élémentaire ou atomique qui correspond à la plus petite partie accessible par l’utilisateur (par exemple, si la ligne de texte est définie comme unité élémentaire alors il n’est pas possible d’accéder séparément aux caractères qui la composent). D’autre part, l’unité utilisable, composée d’une ou de plusieurs unités élémentaires. Une opération invoquée sur une unité utilisable sera exécutée sur toutes les unités élémentaires qui la composent. Informellement, l’unité élémentaire définit le grain minimal pour une opération, et l’unité utilisable définit le grain effectif que peut choisir l’utilisateur.

La littérature fait référence à deux approches en ce qui concerne la modélisation d’un document. La première considère qu’un document n’est qu’une suite de lignes, voire de caractères, la seconde se base sur la structure récursive d’un document décomposé en parties logiques, c’est à dire en sections, contenant des sous-sections et ainsi de suite jusqu’aux paragraphes. Informellement, à une partie logique correspond une entrée dans la table des matières du document. Le modèle de décomposition du document influence la définition de la granularité.

Par exemple, dans la première catégorie, l’éditeur Mace [Newman-Wolfe & al 91] et l’éditeur Mule [Pendergast & Vogel 90] considèrent la ligne comme l’unité élémentaire et un bloc contigu de lignes comme l’unité utilisable. Dans la deuxième catégorie, l’éditeur Quilt [Fish & al 88] [Leland & al 88] définit la partie logique la plus grande (section) comme étant à la fois l’unité

élémentaire et l’unité utilisable. Ainsi, deux utilisateurs peuvent accéder à deux sections concurremment, mais ils ne peuvent pas en revanche accéder de manière concurrente à deux sous-sections de la même section.

La première méthode permet une granularité beaucoup plus fine mais occulte en revanche la structure du document. Par exemple, il est possible de faire un bloc avec les deux dernières lignes du chapitre 1 et les six premières lignes du chapitre 2. Quelle est la sémantique qui peut être associée à un tel bloc. De plus, pouvoir sélectionner un tel bloc signifie que l’on doit pouvoir effectivement y apporter des modifications. Effacer ce bloc entraînera toutefois de profonds bouleversements à la structure du document. En outre, l’inconvénient de cette première méthode est que plus la granularité est faible plus la concurrence peut être grande et donc plus le réseau sera sollicité.

• Gestion des données

La gestion des données peut être caractérisée par deux aspects : (1) données dupliquées ou non dupliquées, (2) données centralisées ou réparties. En première approche, si l’on considère la manière dont les données sont utilisées nous pouvons formuler les deux règles suivantes :

- Si les opérations de consultation sont les plus fréquentes alors il est préférable que les données soient dupliquées et présentes sur chacun des sites des utilisateurs.

- Si les opérations de modification sont les plus fréquentes alors il est préférable d’adopter une solution centralisée avec une seule copie.

Malheureusement, il n’est pas simple de définir dans le cadre de l’édition coopérative laquelle de ces deux approches opposées est la bonne. De plus, les précédentes règles ne tiennent pas compte des événements extérieurs tels que les pannes. La centralisation implique que le stockage se fait sur un seul site serveur alors que la répartition suppose que chacun des sites utilisateurs est responsable du stockage d’une partie des données. L’approche centralisée va à l’encontre de l’autonomie puisque tous les sites utilisateurs dépendent du serveur central. Il constitue un goulot d’étranglement et un site critique en cas de pannes.

L’approche répartie nécessite que les sites utilisateurs offrent la fonctionnalité de serveur en plus de celle de client. De plus, certains sites peu performants peuvent dégrader les performances globales de tout le système en rendant leurs données difficilement accessibles. La solution répartie favorise le travail des utilisateurs possédant leurs données locales au détriment des autres.

Dupliquer les données permet de pallier les pannes des sites de stockage. En effet, si plusieurs copies sont disponibles, la probabilité qu’une copie soit accessible croît proportionnellement. Toutefois, la duplication nécessite des mécanismes de gestion pour assurer la cohérence mutuelle des copies. Sans duplication, dans le meilleur des cas, une donnée peut rester inaccessible pendant toute la durée de la panne du site où elle est stockée (cas favorable où une copie en mémoire permanente existe). En l’absence de pannes, les performances sont toutefois optimales. Ne pas dupliquer les données laisse les utilisateurs à la merci d’une panne de site ou de lien de communication.

• Communication

La communication concerne l’échange d’informations entre les participants géographiquement réparties. Deux types de fonctionnements sont à considérer : le « mode synchrone » où chaque utilisateur voit les interactions des autres participants en temps réel, et le « mode asynchrone » où les modifications ne sont pas immédiatement répercutées globalement.

Le premier mode est désigné par l’acronyme WYSIWIS (What You See Is What I See) qui exprime bien la philosophie sous-jacente. Plusieurs éditeurs dont GROVE [Ellis & al 91] et Mule [Pendergast & Vogel 90] fonctionnent selon ce modèle (Figure 6.2.).

Figure 6.2. Coopération synchrone

Ils sont caractérisés par une granularité fine (caractère ou ligne) qui permet des mises à jour fréquentes (la fréquence des mises à jour étant liée à la taille des données à modifier). Poussé à l’extrême, ce mode implique que non seulement l’espace de travail (les fichiers manipulés) est le même pour tous les utilisateurs mais encore que l’espace d’affichage (généralement la fenêtre de visualisation) est identique. Par exemple, le défilement occasionné par un des utilisateurs se

répercute sur tous les écrans et la position des curseurs de chacun des participants est visible par tous. La (Figure 6.3) montre l’interface de l’éditeur partagé Calliope [Mitchell 96] lorsque deux rédacteurs éditent simultanément une même zone de texte. Le premier a pris le contrôle du mot ‘take’, entouré par un rectangle gris représentant un verrou, tandis que le deuxième a pris le contrôle de tout le second paragraphe (entouré également d’un cadre gris). Ces opérations sont accessibles par un menu déroulant. Les zones de texte entourées de rectangles gris ne sont modifiables que par la personne qui en a demandé le contrôle.

Figure 6.3. Interface de l’éditeur partagé Calliope [Mitchell 1996]

Finalement, un mode purement « asynchrone » (Figure 6.4) considère que les utilisateurs travaillent dans un espace de travail local et qu’ils diffusent leurs modifications quand bon leur semble (par exemple : l’éditeur Prep [Neuwirth & al 90], l’éditeur Quilt [Fish & al 88]). Il permet en particulier de travailler avec des versions brouillons qui sont améliorées avant d’être livrées aux autres participants. Le mode asynchrone favorise généralement le caractère privé du travail de chacun. Certains systèmes considèrent plusieurs modes comme par exemple CES [Greif & al 93] qui propose un mode purement asynchrone ainsi qu’un mode qui autorise un seul participant à modifier le document tout en permettant aux autres participants de voir les modifications en temps réel.

• Cohérence des données

Que les données soient dupliquées ou non, garantir la cohérence des données partagées est important. En effet, des accès concurrents aux données partagées sont possibles et par ce biais peuvent entraîner des incohérences. Par exemple, deux opérations modifiant une même portion de texte peuvent être entrelacées, produisant un résultat non souhaité. Lorsque la duplication est mise en œuvre à ce problème s’ajoute celui de la cohérence mutuelle des copies. Plusieurs copies peuvent effectuer des opérations dans des ordres différents ce qui entraîne une incohérence de

l’ensemble des copies. Différents critères de cohérence sont définis dans la littérature. Ces critères offrent des cohérences plus ou moins fortes au sens des contraintes de sérialisation des opérations.

Garantir la cohérence est important. Toutefois, maintenir une cohérence forte sur les données, obtenir la dernière mise à jour ou suivre les modifications en temps réel n’est pas toujours indispensable. Par exemple, une version obsolète ou incohérente peut s’avérer suffisante lorsqu’il s’agit uniquement d’avoir un aperçu de son contenu, voire seulement son plan. Il est donc utile d’offrir aux utilisateurs plusieurs qualités de service afin de leur laisser le choix entre une réponse rapide avec un résultat éventuellement obsolète ou une réponse plus lente avec une certitude absolue d’obtenir la dernière version. L’utilisation de caches locaux permet par exemple de diminuer les temps de latence pour certaines opérations, au détriment de la cohérence (par exemple, SharedBook [Lewis & Hodges 88], Mace [Newman-Wolfe & al 91].

Figure 6.4. Coopération asynchrone