Class ops.OperationTransformer
Defined in: OperationTransformer.js.
Constructor Attributes | Constructor Name and Description |
---|---|
Method Attributes | Method Name and Description |
---|---|
transform(opSpecsA, opSpecsB)
Currently the priority of ops for tie breaking is defined by how they
are passed to this method.
|
|
<inner> |
transformOpListVsOp(opSpecsA, opSpecB)
|
<inner> |
transformOpVsOp(opSpecA, opSpecB)
|
Method Detail
{!ops.OperationTransformMatrix}
getOperationTransformMatrix()
- Returns:
- {!ops.OperationTransformMatrix}
{?{opSpecsA:!Array.|opSpecsB:!Array.}}
transform(opSpecsA, opSpecsB)
Currently the priority of ops for tie breaking is defined by how they
are passed to this method. Which usually reflects the origin of the ops,
being created locally or coming from the master session.
E. g. the pullbox backend gives this way higher priority to the ops from
the master session.
That is just a randomly chosen rule, because there are no cases known
yet where priority needs to be derived from something non-random.
- Parameters:
- {!Array.} opSpecsA
- sequence of opspecs with lower priority in case of tie breaking
- {!Array.} opSpecsB
- opspecs with higher priority in case of tie breaking
- Returns:
- {?{opSpecsA:!Array.|opSpecsB:!Array.}}
<inner>
{?{opSpecsA:!Array.|opSpecsB:!Array.}}
transformOpListVsOp(opSpecsA, opSpecB)
- Parameters:
- {!Array.} opSpecsA
- sequence of ops with lower priority in case of tie breaking
- {?{optype:string}} opSpecB
- op with higher priority in case of tie breaking
- Returns:
- {?{opSpecsA:!Array.|opSpecsB:!Array.}}
<inner>
{?{opSpecsA:!Array.|opSpecsB:!Array.}}
transformOpVsOp(opSpecA, opSpecB)
- Parameters:
- {!{optype:string}} opSpecA
- op with lower priority in case of tie breaking
- {!{optype:string}} opSpecB
- op with higher priority in case of tie breaking
- Returns:
- {?{opSpecsA:!Array.|opSpecsB:!Array.}}