Greetings webodfers, I'm spending some time in the next 3 weeks improving the behaviour of undo slightly. I am specifically looking at fixing how undo states are created to group things more intuitively for the user. For a nice clear example of the existing problem, try the following steps: 1) Open the editor (http://www.webodf.org/demo) 2) Select 2 or 3 paragraphs 3) Indent these 1 step left 4) Now hit undo If you persist long enough, you can eventually unindent each paragraph. Every second undo appears to do nothing, as this is rolling back the AddStyle operation, which is not really user visible. You'll notice if you look at the Session.enqueue function that it takes an array. In most places, we're quite careful to group all operations from a single user operation into one group. In order to get the next level of improvement to undo, I really need to know what group an operation original executed in. This would allow me to ensure all operations from a single group appear in a single undo state (for example). I have two ideas for how to do this cleanly. Option 1) Add an argument to the signalOperationStart & signalOperationEnd that specify the group being started. The group id can simply be an incrementing number or similar. Pros - * Easy to implement * Group id only needs to be locally unique * Definitely not over-engineered :) * Very transient. Can't be accidentally leaked to other clients etc. * Maximum flexibility to how the server batches up operations e.g., the server can choose to group multiple text inputs in the same region into a single operation Cons - * Very transient! No way to regain the group after the signal has fired * No remote client will ever known how a batch of operations are divided up Option 2) Add a groupid (or transactionid) to each operation. Have the session assign a guid as the groupid so it is generally likely to be globally unique across all clients. Pros - * Clean extension of current system. Easy to implement * Allows remote clients to reconstruct sensible undo states similar to the local client (not that we support collab-undo yet) * Accessible to the local undo, or other consumers that might want to be aware of this (e.g., save points?) Cons - * Increases amount of data sent * No firm decisions as to how remote undo should work yet, so this may not have any bearing on the "right" solution * Server cannot group operations from multiple clients or groups (note, this doesn't stop LOCAL clients from performing clever optimizations however) There are other variations on the theme, but the thoughts are: * Are groups permanent or temporary? * Can groups be modified after being added to the session? (e.g., similar to how SQL transactions work) * How widely known is a group (local or remote)? * If groups are transmitted remotely, how do other clients know when they have received all operations in a single group? * Again, if remotely received, can remote clients interleave ops from multiple groups? I would like to open the email for discussion. Do people have any preference between option 1 or 2 (or another suggestion entirely)? Are there other opinions about how these groups should work? Is there obvious issues I've missed? I plan to start cutting code next week Tuesday AEST, so there are some time pressures for reply. Having said that... we can always tweak it later. Neither option is a lot of code so far :) Cheers, -- Philip Peitsch Mob: 0439 810 260