| 7 | | == Overview == |
| | 9 | The set of ProLib primitives should have the following characteristics: |
| | 10 | * each primitive should be representable as a plain-text string of characters |
| | 11 | * all the primitives together should describe some sort of a language which should correspond to all the functionality which the ProLib provides |
| | 12 | * this way everything that happens inside Sophie 2 should be representable as some sort of a program written in this language |
| | 13 | * this program could then be easily: |
| | 14 | * transmitted to a server over the network |
| | 15 | * viewable and understandable for debugging purposes |
| | 16 | * converted to appropriate ProLib functions |
| | 17 | * both primitives and changes form the type of information that will be stored in the ChangeManager |
| 12 | | * Primitive operations about changes which include the following: |
| 13 | | * create - which should create a change which should have an id. The design section should decide on the uniqueness of the id of a change. This is needed to manage changes on a server for example. |
| 14 | | * destroy - which should destroy a change by an id. |
| 15 | | * set - should be able to set the change with an id for a property. This will be helpful if for example a change is to be altered so that consistency is kept. There will occur situation with changes on a server where some part of a composite change should be altered. Imagine for example several people managing a book at the same time. |
| 16 | | * Changes types: |
| 17 | | * Change - a simple change. |
| 18 | | * !GroupChange - a composite change that is constructed of simple changes. |
| 19 | | * !UnmanagedChange - a change that is supposed to be managed in a special way. Its undo and redo will be implemented as the situation requires. For example - save a book may be a unmanaged change. If the user creates a frame with a movie content (with a media file of over 700Mb), deletes the frame, deletes the media file and requests a undo - the change may become a unmanaged. If the user had not deleted the media file the change would have been a normal change that can be undone. |
| 20 | | * '''Note''' - the primitive operations described above should be possible having in mind these types of changes. Also have in mind that the change types are already implemented in one way or another. |
| 21 | | * A decent documentation should be created that explains the primitives - change types and operations with them. |
| | 22 | * Primitives should include the following operations: |
| | 23 | * ''create'' |
| | 24 | * each object the ''create'' primitive creates should have a unique id |
| | 25 | * this primitive should be able to create a ProObject and return its id |
| | 26 | * or create a Property for a given ProObject and return its id |
| | 27 | * create a ProList and return its id |
| | 28 | * ''destroy'' |
| | 29 | * should destroy an object given its id |
| | 30 | * ''set'' |
| | 31 | * should be able to set a value to an object given its id |
| | 32 | * A few ProList operations should be available: |
| | 33 | * ''add'' |
| | 34 | * adds an object to a ProList given its id and position to be added to |
| | 35 | * ''remove'' |
| | 36 | * removes an object from a ProList given its id and position to be removed from |
| | 37 | * the ''set'' operation should be adapted to accept a ProList, object and a position and should assign the given object to the given position in the given ProList |
| | 38 | |
| | 39 | * All ids used should be unique |
| | 40 | |
| | 41 | * Synchronization problems with list operations should be considered |
| | 42 | * An idea for solving those problems should be proposed |
| | 43 | |
| | 44 | * Add more operations if needed |
| | 45 | |
| | 46 | * Describe Changes decomposition to Change primitives, its purpose and provide a use-case |
