Ohm Force Developer LibraryFlip Overview

Flip Overview

• About Flip
• How it Works
  • Building a Transaction
  • Validation
  • Validation Approval
  • Validation Refusal
• Interfacing with the Model
• Undo/Redo System
• Threading System
• Document Format, Conversion

How it Works

Building a Transaction

The client of the Flip framework will directly modify the model by either :

• modifying a value by assigning it
• insert a new object in a container
• erase an object from a container

Assigning a value is done with the operator = and modifying a container follows the same kind of prototypes as found in the standard library ( insert , erase , etc.) which makes the use of Flip quite natural.

In the background, each operation is translated in real-time in a simple assembler. When the client of the library manipulate the model, Flip will apply and record all the changes made to the model and will make a program in that assembler.

This program is also a transaction in the sense that applying a transaction will transform the model from a valid state to another valid state.

Validation

This transaction is then sent to the server. The server will interpret the assembler to make the changes to its own model. The transaction is then validated by the server. Validation ensure that the model is consistent and is done in two steps :

1. structural validation
2. logical validation

Structural Validation

Structure validation is handled by Flip. It ensures that an object can be either modified, inserted or erased. For example structure validation may fail if two clients tries to erase an object concurrently. In that case the second transaction is rejected. Another example would be to reject a transaction where a client tries to change a value of an object that was erased concurrently.

Logical Validation

Logical validation is handled by the client. It ensures that the model is consistent relative to the meaning that the the client assign virtually to the model structures. For example the client might want to ensure that for a container which the client assign the meaning of length, that its element which could be defined with a position and length do not go passed the length of container, that is to ensure :

element._position + element._length <= container._length

0 <= element._position

0 <= element._length

0 <= container._length

This kind of validation is possible in Flip, as it is dynamic (it is a program that the client writes) rather than static or semi-static (like a XML/DTD)

The architecture of Flip allows to write validators very quickly, in a tree parsing fashion.

Validation Approval

When the two staged validation is good, the transaction is considered as accepted. The server will broadcast the transaction for execution to the other clients, and will send an approval to the original client.

Validation Refusal

When the two stages validation is wrong, the transaction is considered as refused. The server will send a disapproval to the original client which will rollback the transaction.

When another client execute the transaction, it will make all the changes needed by that transaction. When it is done and succesfully applied, the client observers are called.