Collaboration with asynchronous data channels

I am reading documentation about collaboration support and I found this paragraph:

Of course, with asynchronous data channels (such as long polling in the collab demo or web sockets), you’ll need somewhat more complicated communication and syncronization code.

I thought existing code for collaboration does work over web sockets? Am I missing something? What syncronization more do you have in mind? That the server side should only execute one authority call at once? If I would have horizontally scaled app?

Or is this because the simple authority just broadcasts changes to all clients? I do not really see anything more fancy in this code either?

Is there any implementation for a more complete authority?

1 Like

That is just a very minimalistic example of how the code would work having the client and the authority running on the same thread. The collab example is asynchronous and uses long pooling and it is also possible to implement it with web sockets.

I would recommend starting with the synchronous code running in your browser, understand how it works, then move to understanding the collab example and from there you can decide how to implement it yourself using web sockets or whatever else you choose.

Yes, the collaborative editing demo from the website is a more full-featured, long-polling-based example.

OK, so if I understand correctly, that “more complicated communication and syncronization code” is about how to organize that the server side works as a single threaded entity. If for example, you have multiple processes when horizontally scaling and so on. And another issue is how to handle connection breaking to the server.

But there is no extra need to do something fancier on the server. Like with OT, you have to transform things on the server. Here you still just have to decide if an operation should apply or not, and this is it.

That quote is just unclear a bit. Or am I still missing something? (I read both the guide and checked the colab code.)

No, I was indeed referring to regular complications around asynchronous communication – the ProseMirror-level concepts remain the same.

1 Like

Really cool. Thanks.