Undo and Redo

Concepts

• Read request. A read request queries statements of a given snapshot.

• Write request. User issues write requests using RequestProcessor.syncRequest and RequestProcessor.asyncRequest. A write request makes a set of modifications.

• Change set. Changes are grouped into identified change sets. The database is completely specified by a single change set list.

• Change list. Describes all modifications to the database from empty database.

• Remote change list. Remote changes that are common for local and remote server and complete.

• Partial change list. Contains remote changes that have been synchronized but are not complete i.e. remote server still contain change sets that could be inserted into the partial list.

• Local change list. Contains changes made locally.

• Change notification. A change set which reflects changes applied to some snapshot. This is not necessarily part of the change list!

• User context. Undo and redo is applied in some user context. The context stores a set of operation identifiers which can be used to perform undo

• Operation identifier. Each write request is performed with an operation identifier. Multiple requests can share a same identifier. The identifier is used to group relevant undo operations.

• Snapshot. A set of clustered statements determined by some specified position of the change list.

• Remote server.

• Local server.

• Client.

Model

• A single write request produces a single change set. The write request must supply an operation identifier.

• Nesting write requests (with RequestProcessor.syncRequest) contribute to a single change set.

• Requests which are asynchronously invoked (with RequestProcessor.asyncRequest) begin a new change set

• Listeners which (asynchronously) fire write requests can obtain the operation identifier of the ongoing write request from UndoRedoSupport.

• Undo and redo are performed using the operation identifiers.

Transaction Handling

• Read and write requests require transaction.

• Transaction is acquired from server.

• During read transaction several clients can read simultaneously.

• During write transaction serveral change sets can be created. Other clients are notified of changes in the change list each time a change set is committed.

• Server can ask client to relinquish transaction. Client must reply but it can decline to relinquish the transaction.

In the transaction scenario above:

• Flush cluster change set means that client sends changes made to one cluster. This cluster change set can be partial and contain same statements (claim), the same statement can be delete more than once (deny) and the same statement can be added and deleted.

• Change notification contains only change state position of last change set in the server. If client is not hyperactive it can ignore the notification. Other possibilities are query for read or write transaction.

• Client is responsible maintaining change state position of last transaction when accessing snapshot. This is used as input parameter in read and write transaction requests. If necessary server will send new change sets to client before serving clusters.

Undo

• Reverts the effect of given operation. Each operation has identifier and is maded of one or more change sets. Undo marks the given change sets removed from the local change list and produces one new change set reverting the effects of the given old local change sets. Server sends change notification to each client excluding the initiating client.

Redo

• Reverts the effect of given undo operation. Each redo produces one change set reverting the effects of given (previous) undo. Server sends change notification to each client excluding the initiating client.

Publish

• Send given local change sets to remote server. Requires that the local server has fetched all remote change sets.

Synchronize

• Fetch given remote change sets from remote server to local server. The change sets are inserted before local changes to the change set list. This can result to conflicts in the following local change sets.

Refresh

• Server sends change notification to each clien when its change list changes excluding the client initiating the change. The change notificaton contains change list position of the last change set at the time of the notication. Client can then ask for read or write transaction to get the new change sets. The new change sets are sent when the transaction is given. Client can also skip the notification and update its state only when it needs to read or write.

File On Server

Resource can have a value or file. If resource has a file then the file can be read and written in parts and committed with the change sets.

Server Data Model

Change Sets

• Change set does not have duplicates (i.e. same statement added twice).

• Local change set list can have duplicates (i.e. same statement added twice in different change sets).

Calculation of change set rev L2 (fourth local change set above) is as follows. A rev L2 is formed by removing every statement added in L2 and adding every statement removed in L2. Resource values are given the old values. Added statements in L3 override removed statements in rev L2. Removed statements in L3 override added statements in rev L2. Resources created in L2 must not be referred in L3.

Calculation of change set eff R4 (sixth local change set above) is as follows. Change set R4 is transferred from remote. Each local change set is gone through and added statements in local change sets override removed statements in R4. Removed statements in local change sets override added statements in R4.

Examples

Diagramming

• User context = some diagram

• Write request 1 = populate element, new operation identifier stored by UI

• Write request 2 (fired in listener) = mapping to create component, uses operation identifier from WR1

Property Editing

• User context = some property view

• Write request 1 = edit proerty value

Model Browsing

• User context = some model browser

• Write request 1 = rename of configuration diagram name