Gestion des sessions collaboratives

[ggrossetie]

D'après les retours que nous avons reçu, il est assez fréquent pour les utilisateurs de laisser une session collaborative ouverte sur une longue période de temps.

D'un point de vue fonctionnelle, il nous semble important de rapprocher le mode collaboratif du mode d'édition "classique".

L'idée de cette discussion est de recueillir des idées afin de se mettre d'accord sur la direction à prendre ainsi que sur les étapes intermédiaires pour y arriver.

[ggrossetie]

En lisant (à nouveau) la documentation de Y.js et les discussions autour de cet outils je pense que la bonne approche technique est d'enregistrer un document Y.js comme "copie de travail".

This means, that you need to persist the Yjs doc (Y.encodeStateAsUpdate(ydoc)) instead of the pure text content. If you would like to index the text document, you can store it besides the Yjs encoded document.

Many people have tried to solve this problem by implementing some kind of protocol that discards the Yjs document. But you will always run into duplication troubles if the client disconnects for a time and then reconnects with existing content. Even if you would use Operational Transformation (e.g. using shared) you need to persist the log of all operations that were ever created in order to ensure convergence. There is no difference in Yjs - you need to persist the log of all operations (the Yjs document) in order to ensure that clients can always sync and that there is no duplication. The advantage of Yjs is that the encoded document is actually pretty small even for long editing traces and that it works peer-to-peer without a central authority.

I know there are concerns that the Yjs document is larger than the pure text document. So naturally, you would like to discard the Yjs document. The same goes for the operation log in ShareDB. As I highlighted above, there are many advantages of persisting the operation log. You can probably think of a way to discard the operation log after a few days - but I would also like to discourage that idea. This is extremely hard to implement correctly and you won’t be able to use other Yjs modules like y-redis or y-indexed for improved load-time. The Yjs document only has an overhead of 45% in practice for long editing traces. This is a small price to pay for convergence.

-- dmonad (Y.js creator) https://discuss.yjs.dev/t/how-to-fetch-init-data-in-server-side/158/2

L'idée est que l'ensemble des changements sur la copie de travail se feront au travers de Y.js. Si on modifie le document seul, on aura quand même le log des opérations mais cela garantit que dès qu'un utilisateur rejoint la session, il va récupérer l'ensemble des opérations et être synced.

[thom4parisot]

Oui super ! Et quand y'a un événement de "changement" dans y.js, alors on le persiste dans la workingCopy c'est ça ?

[thom4parisot]

Du coup ça résoud le problème de la "dernière personne qui part". On n'est pas obligé d'enregister une version automatiquement ; sauf à améliorer l'UI de cette fonctionnalité pour que ça soit plus parlant (donner de bonnes raisons de le faire).

[ggrossetie]

Oui super ! Et quand y'a un événement de "changement" dans y.js, alors on le persiste dans la workingCopy c'est ça ?

Oui c'est ça, peut être avec un debounce pour ne pas faire trop de mises à jour dans la base de données

Du coup ça résoud le problème de la "dernière personne qui part". On n'est pas obligé d'enregister une version automatiquement ; sauf à améliorer l'UI de cette fonctionnalité pour que ça soit plus parlant (donner de bonnes raisons de le faire).

Oui et on ne perd plus les changements des sessions collaboratives car les changements sont enregistrés tout le temps.
Par contre, il faut qu'on garantisse que l'édition collaborative fonctionne bien car on n'aura plus que ce mode d'édition.