Collaboration en temps réel
Coordonnez les modifications simultanées avec OT, HTTP, WebSocket et persistance.
Utilisateurs et agents connectés modifient le même document. Les changements sont locaux d’abord ; le serveur confirme leur ordre et les distribue, conciliant réponse immédiate et cohérence éventuelle.
Concurrence et conflits
Univer utilise OT (transformation opérationnelle). Le client regroupe les opérations en changesets ; le serveur les transforme selon les révisions confirmées. Si Alice modifie C2 pendant que Bob insère une colonne avant B, la modification suit la cellule vers D2. Annuler et rétablir s’ajustent aussi, sans résoudre tous les conflits métier.
Une opération impossible à transformer ou appliquer bloque l’édition du document. CollaborationConflict fournit la cause et les changements locaux non confirmés. Conservez-les avant de recharger. Consultez la récupération et la conception OT.
Canaux et reconnexion
| Canal | Rôle |
|---|---|
| HTTP | Charger snapshots et changements, obtenir un Session Ticket, soumettre les changesets. |
| WebSocket | Maintenir Session et Room ; recevoir ACK, changements distants et Presence. |
Un Ticket à usage unique permet de se connecter puis de rejoindre la Room. Presence partage membres, curseurs et sélections. Une connexion active ou une requête HTTP réussie ne confirme pas l’enregistrement. Combinez ACK, état collaboratif et modifications en attente.
Après une coupure, conservez les changements non confirmés, récupérez les révisions manquantes et renvoyez-les. Le serveur déduplique les envois. Consultez l’état de synchronisation et Presence.
Persistance et snapshots
Enregistrez changesets et révisions confirmés, puis générez les snapshots selon une politique. Le chargement applique les modifications postérieures au snapshot ; une image par édition n’est pas nécessaire. Voir Headless et calcul serveur. Historique, commentaires et Worktree sont des extensions.
Architecture de déploiement
- Un nœud : assemblez Transport, Endpoint, Service et Database Adapter dans Node.js. Memory sert aux tests temporaires, SQLite au local ou aux petits déploiements. Les autres bases nécessitent un adaptateur applicatif.
- Extension : en plus de la persistance partagée, coordonnez diffusion inter-nœuds, Presence, validation des Tickets et cohérence. Ajouter des processus ne suffit pas ; suivez la conception de votre version.
- Tâches lourdes : isolez les conversions intensives en CPU.
Consultez les modules, le déploiement et l’exemple multinœud.
Performances et capacité
Les benchmarks et chiffres de capacité de la version actuelle restent à fournir. Ils dépendent des documents, de la fréquence, des participants et de l’environnement. Mesurez confirmation, affichage distant, changesets par seconde, diffusion et mémoire.
Intégration et périmètre
Commencez par la vue générale et l’exemple à deux navigateurs. Branchez identité et autorisation via Middleware, choisissez un Database Adapter persistant et vérifiez la conservation après redémarrage.
Le noyau couvre Sheet, Doc, Slide, Canvases et Relational Table, pas PDF. L’application fournit identité, autorisation, gestion des fichiers et politiques de stockage.
Que pensez-vous de ce guide ?