[WebODF] Undo & Operation groups

[Philip Peitsch]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/webodf/attachments/20140117/83916bcd/attachment.html>