A simple optimistic auto-locking scheme

[justvanrossum]

Adjacent to #19, here is the outline of a simple auto-locking scheme.

The idea is that we assume a glyph is unlocked/editabe, expecting this to be the common case by far, and simply go ahead with an edit (say, drag some points). But it will stop an edit-in-progress once the system finds out it is already being edited by someone else. I would like multiple clients to be able to have a glyph in "edit mode", so I don't want to tie glyph locking to the edit mode. I would like to lock only when actual editing takes place.

Prerequisites:

• The unit of locking is "variable glyph" (but could also be "kerning", "font info", etc.)
• A lockable object has a version token

Steps:

• Client: tells server it will edit, and the object version token it has, but does not wait for permission (we don't want lag)
• Server: if another client is editing this object: reject edit, send rejection notification to client
• Server: if the current version token doesn't match the version token the client sends: reject edit, send rejection notification to client
• Client: until the reject notification is received, just continue sending edit changes, which will be ignored by the server; then: rollback the edit locally, notify user why the edit was rejected
• Client: if the edit is done, send final edit message, then await the answer, as the edit can still be rejected at this point. If rejected: rollback edit, notify user. If not rejected, receive new version token.

(The server could let clients pro-actively know which glyphs are locked, which would be a little friendlier for the user in most cases. But the above is still necessary to avoid race conditions: what if two users start editing a glyph at roughly the same time, before either can be notified? The server will have to reject one of them while it is already editing.)

This is much simpler than a full CRDT, and has the following drawbacks:

• The client-server connection must exist: editing cannot continue if the connection gets dropped
• No concurrent edits possible on the same object: once locked, no other client can edit. Practically, this means that while one user is editing the Regular of a glyph, no one else can edit the Bold.

Compared to RoboCJK, this has the following advantage:

• Locking starts only when an actual edit is made, and ends immediately after the edit (say, a point drag)

This scheme can be made to work with RoboCJK's locking mechanism:

• Fontra client initiates edit, and goes ahead without waiting for permission
• Fontra server does the steps outlined above to see if any other Fontra client is editing
• Meanwhile, Fontra server asks robocjk for a locked glyph
• If this fails: reject edit
• If succeeded, compare received (locked) glyph data with previously received (not locked) glyph data; if different: reject edit (in this case, the version token could be a hash of the glyph data)
• After edit: unlock robocjk glyph

(This will cause quite some traffic between the Fontra server and the RoboCJK server, if edits come in quick succession, such as when dragging points. Perhaps it can be streamlined, eg. by delaying unlocking a little, so rapid successive edits can use the same lock.)

[justvanrossum]

This is partially done in googlefonts/fontra-rcjk#27, at least on the back-end level. We still need a more integrated method for live changes, mostly in fonthandler.py.