History steps and collab

1

A few related points I was hoping to suggest/discuss:

  • Undo/redo steps

I was wondering if undo and redo can be implemented as their own kind of steps instead of replaceStep etc. I see a few advantages here -

space - when these steps are stored on the database they will be small and constant in size as opposed to what happens for example if the user select an entire document then hits del then undo then redo which means the entire document is stored an extra two times.

Bandwidth - this becomes really important for collab, in the scenario above, all clients will be sent the entire document twice, instead of just two small steps

Also - this will allow adding special properties to these steps, in particular the clientID which leads me to the second point

  • Undoing other clients steps

At the moment, collab does not add steps received from other clients to collab history. There is a strong use case for that. If I type at the end and another user edits in the middle, I want to just type and be able to undo/redo without his edits affecting me, as if he’s not there

However, there is also a very strong use case for the other way. I went for coffee and when coming back realized another user messed up the document. I now want to undo those edits but can’t. This will be incredibly useful and will remove the need for implementing complicated versioning etc giving a lot of peace of mind to the user

One idea I was thinking about is for history to receive all undo/redo in special steps as suggested above and store the client Id in them. There can then be a command (connected to a menu button for example) to toggle whether subsequent undo/redo will or will not include other client’s changes. This will give the user the best of both worlds in a relatively simple way (compared to automatically generated revisions for example)

  • Pushing steps to history undo

Again bringing up the discussion here as there was no resolution. Can there be a way to allow a collab client to load previous steps and push them to the history undo buffer so as to allow travel back in the document history ?

I played with that quite a bit and I’m pretty sure it’s not possible without API support in history to allow pushing (inverted) steps. Has there been any more thinking on getting this done ? This will be an incredibly strong feature.

Thanks !

2

I don’t see how that could possibly help. (They’d still need to encode the same information, so they’d be exactly as big as they are now.)

That’s not how I implemented it, since that’s generally understood to not be the right way to handle collaborative undo, but feel free to hack something up that works that way if you want it.

Yeah, as you mentioned, there’s another thread open on that, so maybe don’t keep bringing it up.

3

I don’t see how that could possibly help. (They’d still need to encode the same information, so they’d be exactly as big as they are now.)

They’ll be as big as they are now on the client (that is they will take the same space in the history undo buffer, but they will be tiny on the database and when sent to/from clients (just a step with a type ‘undo’ and if needed the number of steps but no content).

ctrl+z will generate and dispatch such a step and history will consume it, pop the fragment from it’s undo buffer and update the state.

does that makes sense ?

That’s not how I implemented it

ok fair enough, how do you see clients undoing changes by other clients if they don’t want them ? some kind of a revision mechanism ?

Yeah, as you mentioned, there’s another thread open on that, so maybe don’t keep bringing it up.

sure, just there was no more input there so don’t know if this is a yes, no or maybe ?

4

another two points I was thinking about, using undo/redo steps will make it possible to persist the history between two instances using the same clientID. This is in fact a very common scenario, a document opened on multiple machines/devices of the same user. It would be great to undo on the home machine, go to work and redo there for example …

also it will make it possible for other plugins to respond to undo/redo steps dispatched to them, though I can’t think of a use case ATM.

These are just ideas, I don’t know how difficult this will be to implement or what other issues will arise.