Ticket	Summary	Owner	Status	Type	Component	Priority	Effort	Importance
#149	PRO_CHANGE_PRIMITIVES_R0	gogov	closed	planned_task	PRO_LIB_ENTITIES	3	1	18
Reported by Astea, 4 years ago.
Description	wiki page: PRO_CHANGE_PRIMITIVES_R0 - effort: 1d
Analysis_owners	peko
Analysis_reviewers	orliin
Analysis_score	1
Design_score	0
Imp._score	0
Test_score	0

Analysis

Overview

Changes should be able to be decomposed into ProLib primitives.

The set of ProLib primitives should have the following characteristics:

• each primitive should be representable as a plain-text string of characters
• all the primitives together should describe some sort of a language which should correspond to all the functionality which the ProLib provides
  • this way everything that happens inside Sophie 2 should be representable as some sort of a program written in this language
  • this program could then be easily:
    • transmitted to a server over the network
    • viewable and understandable for debugging purposes
    • converted to appropriate ProLib functions
• Changes form the type of information that will be stored in the Histories responsible for logging Changes in ResourceSpaces

This task is to develop a set of primitives which fulfills the requirements above.

Task requirements

• The set of primitives should look like this:
  • <id> probj-create <class-name>
    • creates a new ProObject given its class name and returns the id of the newly created ProObject
  • probj-destroy <proobj-id>
    • destroys an existing ProObject given its id
  • probj-set <probj-id> <prop-name> <value>
    • sets a new value to a Property by its name of a ProObject given its id
  • prolist-add <proobj-id> <prolist-name> <pos> <object>
    • adds a new object at a given position to a given ListProperty of a given ProObject
  • prolist-remove <proobj-id> <prolist-name> <pos>
    • remove the object at a given position of a given ListProperty of a given ProObject
  • prolist-set <proobj-id> <prolist-name> <pos> <object>
    • sets a new object as a value of a given position to a given ListProperty of a given ProObject
  • undo
    • undoes the last Change in the History
  • redo
    • cancels the last Change in the History, if it is an UndoChange
  • skip <change-id>
    • skips a Change in the History given its id

• All ids used should be unique
  • Maybe UUIDs could used

• Synchronization problems with list operations should be considered
  • An idea for solving those problems should be proposed
    • For instance the problem with positions and merging. Some sort of smart positions could be implemented

• Each primitive should correspond to a Change in the History

Task result

• Rough implementation
• Good description of the primitives in CORE_CHANGES
• Use-case for the primitives with diagrams

Implementation idea

• For the use case describe what happens when a Sophie client is connected to a Sophie server and how the Histories running on both sides work together

Related

GROUP_CHANGE_R0?

PRO_CHANGE_COMMONS_R0
PRO_CHANGE_TRANSACTION_SAFETY_R0
PRO_CHANGE_COMPOSING_R0
PRO_CHANGE_MANAGER_R0
PRO_CHANGE_UNDO_MANAGER_R0

How to demo

• Show primitives description
• Show and explain the use case

Design

Implementation

Testing

Comments