{"type":"doc","content":[{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"extension","attrs":{"layout":"default","extensionType":"com.atlassian.confluence.macro.core","extensionKey":"toc","parameters":{"macroParams":{},"macroMetadata":{"macroId":{"value":"0c60b74c-63a8-4205-81eb-5d56766b8431"},"schemaVersion":{"value":"1"},"title":"Table of Contents"}},"localId":"d458427d-35bf-43e8-b658-1af38464fb14"}},{"type":"heading","attrs":{"level":2},"content":[{"text":"Introduction","type":"text"}]},{"type":"paragraph","content":[{"text":"This document will give practical guidelines for thread safety when using Vortex SDK. Care must be taken when developing plugin extensions, objects and modules. This document is targeted to developers who make their own extensions and modules in c++.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"What is thread safety for Vortex SDK","type":"text"}]},{"type":"paragraph","content":[{"text":"Vortex SDK is a real-time simulation framework that uses several multi threading techniques to improve performances. Vortex SDK simulation is considered thread safe when all extensions are used by only one thread at a time.","type":"text"}]},{"type":"paragraph","content":[{"text":"A Vortex SDK application has a main simulation thread; this is where ","type":"text"},{"text":"VxApplication::update()","type":"text","marks":[{"type":"em"}]},{"text":" is called. It is the heartbeat of the simulation. The ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":" and several modules will create other threads for specific purposes. The dynamics module will spawn several threads to efficiently calculate a simulation step. The graphics module will also spawn threads to efficiently feed data to the graphic card. The ","type":"text"},{"text":"QtModule","type":"text","marks":[{"type":"em"}]},{"text":" will also create a thread in which the UI will be updated. In general, any module (even user modules) could spawn threads to efficiently perform its tasks in ","type":"text"},{"text":"ISimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":" update callbacks. Those user threads will use the extensions managed by the module to get data and to output data: how and when to get data and to inject data is the main topic of this document.","type":"text"}]},{"type":"paragraph","content":[{"text":"In order to avoid threading and synchronisation issues, it is important to understand the order of operations in a Vortex application. VxApplication does simply one thing: it updates modules one by one. In the simulation main thread (called simply the simulation thread), the following operations are done during application update():","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Event-based operations","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"changing application mode, ","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"any asynchronous operations that were requested","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"events are dispatched to their event listeners","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"delayed functions are executed ( see ","type":"text"},{"text":"VxSim::ApplicationContext::execute:Later ","type":"text","marks":[{"type":"em"}]},{"text":").","type":"text"}]}]}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Simulation time and frame number is incremented","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"On a network slave, the network data related to the current simulation frame is deserialized and pushed to the extensions, potentially calling observers on extensions.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The callback ","type":"text"},{"text":"ISimulatorModule::preUpdate()","type":"text","marks":[{"type":"em"}]},{"text":" is called on all modules","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The callback ","type":"text"},{"text":"ISimulatorModule:update()","type":"text","marks":[{"type":"em"}]},{"text":" is called on all modules","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"if present, the Dynamics module will use several threads to process the current content and calculate the object positions at the current simulation time","type":"text"}]}]}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The callback ","type":"text"},{"text":"ISimulatorModule::postUpdate()","type":"text","marks":[{"type":"em"}]},{"text":" is called on all modules","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"if present, the Graphics module will use several threads to do the 3D visualization using the current simulation content","type":"text"}]}]}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"On the network master, the network data is serialized and sent.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Any pending delayed functions are executed.","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"All those actions are done sequentially. There is one ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":" per process.","type":"text"}]},{"type":"paragraph","content":[{"text":"There are several helper threads in a Vortex application, but they are not relevant to thread safety issues. They are completely managed by the SDK and deal generally with hardware: devices, network, graphics, sound. ","type":"text"}]},{"type":"paragraph","content":[{"text":"The thread which is particularly vulnerable to threading issues is the UI thread since it needs to get current information about the simulation.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"General Vortex Studio SDK thread safety guidelines","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Object lifetime management","type":"text"}]},{"type":"paragraph","content":[{"text":"All first class objets (","type":"text"},{"text":"VxExtension","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"VxObject","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"VxSimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":") are reference counted and should always be kept in smart pointers. For more information on reference counting see ","type":"text"},{"text":"Wikipedia","type":"text","marks":[{"type":"link","attrs":{"href":"https://en.wikipedia.org/wiki/Reference_counting"}}]},{"text":". There are four flavors of smart pointers in Vortex SDK. ","type":"text"},{"text":"Vx::VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxSim::VxSmartInteface","type":"text","marks":[{"type":"em"}]},{"text":" are strong references and will increment the reference count to keep an object alive. ","type":"text"},{"text":"Vx::VxWeakPtr","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxSim::VxWeakInterface","type":"text","marks":[{"type":"em"}]},{"text":" are weak references and will simply track the lifetime of the object they refer.","type":"text"}]},{"type":"heading","attrs":{"level":5},"content":[{"text":"Creation and destruction of objects","type":"text"}]},{"type":"paragraph","content":[{"text":"Creation of any object is done with the factory key and ","type":"text"},{"text":"VxExtensionFactory","type":"text","marks":[{"type":"em"}]},{"text":". It is recommended to call ","type":"text"},{"text":"VxExtensionFactory::create()","type":"text","marks":[{"type":"em"}]},{"text":" only in the simulation thread. Currently, some objects must be created in the simulation thread : creating them in any other thread might cause initialization problems.","type":"text"}]},{"type":"paragraph","content":[{"text":"Since extensions are referenced counted, they are destroyed when the reference count reaches 0. There can be no guarantee that the destructor is called in any specific thread: it is called when the last reference is gone. Therefore, extension should not assume it will be called in the simulation thread.","type":"text"}]},{"type":"panel","attrs":{"panelType":"error"},"content":[{"type":"paragraph","content":[{"text":"Extension constructor and destructor are not the ideal place to initialize internal values of the extension. The correct way is to override ","type":"text"},{"text":"IExtension::onActive()","type":"text","marks":[{"type":"strong"},{"type":"em"}]},{"text":" and ","type":"text"},{"text":"IExtension::onInactive()","type":"text","marks":[{"type":"strong"},{"type":"em"}]},{"text":". Those callbacks are guaranteed to be called in the simulation thread, when the extension is preparing to be used in the simulation. This is true for all ","type":"text"},{"text":"IExtension","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"IObject","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"ISimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" is for Objects : ","type":"text"},{"text":"VxExtension","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"VxObject","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"VxSimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]}]},{"type":"paragraph","content":[{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxWeakPtr","type":"text","marks":[{"type":"em"}]},{"text":" do not allow any casting. It can only keep first class objects directly, and does not give easy access to the plugin interfaces so their use is very limited. ","type":"text"}]},{"type":"paragraph","content":[{"text":"Using ","type":"text"},{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" ensures that the object is not deleted until it is no longer referenced. When an object is referenced with a ","type":"text"},{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":", its reference count is increased thus making certain the object is not deleted. The reference count will be decreased (and the object may be deleted) when the object is removed from the ","type":"text"},{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" or if the ","type":"text"},{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":" is deleted.","type":"text"}]},{"type":"paragraph","content":[{"text":"VxWeakPtr","type":"text","marks":[{"type":"em"}]},{"text":" is a weak reference to an object. It is used to keep track of the lifetime of an object. A weak pointer is typically used to break ","type":"text"},{"text":"reference cycles","type":"text","marks":[{"type":"link","attrs":{"href":"https://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles"}}]},{"text":". ","type":"text"},{"text":"VxWeakPtr","type":"text","marks":[{"type":"em"}]},{"text":" can be queried for validity, and the method ","type":"text"},{"text":"VxWeakPtr::lock()","type":"text","marks":[{"type":"em"}]},{"text":" must be used to have access to the object itself.","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"VxSmartInterface","type":"text","marks":[{"type":"em"}]},{"text":" is for Interfaces : for class derived from ","type":"text"},{"text":"ISimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"IObject","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"IExtension","type":"text","marks":[{"type":"em"}]}]},{"type":"paragraph","content":[{"text":"VxSmartInterface","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxWeakInterface","type":"text","marks":[{"type":"em"}]},{"text":" give immediate access to the desired plugin interface. The also allow east casting between interfaces in the same object.","type":"text"}]},{"type":"paragraph","content":[{"text":"VxSmartInterface","type":"text","marks":[{"type":"em"}]},{"text":" is used to reference an extension that has interface U. It is similar to ","type":"text"},{"text":"VxSmartPtr","type":"text","marks":[{"type":"em"}]},{"text":", but gives immediate access to the interface. It can be used to check the presence of an interface. It will ensure the object is not deleted until it is no longer referenced.","type":"text"}]},{"type":"paragraph","content":[{"text":"VxWeakInterface","type":"text","marks":[{"type":"em"}]},{"text":" is a weak reference to an object having the interface U. Its usage is similar to that of ","type":"text"},{"text":"VxWeakPtr","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]},{"type":"panel","attrs":{"panelType":"info"},"content":[{"type":"paragraph","content":[{"text":"In general, ","type":"text"},{"text":"VxSim::VxSmartInterface","type":"text","marks":[{"type":"em"}]},{"text":" is what you want.","type":"text"}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Extensions thread safety guidelines","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"User defined callbacks","type":"text"}]},{"type":"paragraph","content":[{"text":"The user defined callback are the virtual methods on an extension interface (","type":"text"},{"text":"IDynamics","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"IGraphics","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"IExtension","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"ISimulatorModule","type":"text","marks":[{"type":"em"}]},{"text":", etc..) that a developer must implement to give a specific behavior to a user defined extension. Those methods are either pure virtual (therefore must be defined) or are simply virtual (the default behavior is to do nothing).","type":"text"}]},{"type":"panel","attrs":{"panelType":"info"},"content":[{"type":"paragraph","content":[{"text":"As a general rule, it is safe to assume that any user defined callbacks will be called in the simulation thread. So it is safe to query and use other extensions in those callbacks.","type":"text"}]}]},{"type":"paragraph","content":[{"text":"There are very few exceptions to this rule. ","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IExtension","type":"text","marks":[{"type":"em"}]}]}]}]},{"type":"paragraph","marks":[{"type":"indentation","attrs":{"level":2}}],"content":[{"text":"IExtension::onStateSave()","type":"text","marks":[{"type":"em"}]},{"text":" can be called on a different thread. This is a performance optimization when getting the data for a ","type":"text"},{"text":"Keyframe","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IObject","type":"text","marks":[{"type":"em"}]}]}]}]},{"type":"paragraph","marks":[{"type":"indentation","attrs":{"level":2}}],"content":[{"text":"IObject::isCompatible()","type":"text","marks":[{"type":"em"}]},{"text":" can be called from ","type":"text"},{"text":"any","type":"text","marks":[{"type":"underline"}]},{"text":" thread. ","type":"text"},{"text":"IObject","type":"text","marks":[{"type":"em"}]},{"text":" first checks to see if adding is possible, then it will dispatch the actual addition to be done in simulation thread.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"IQtPage","type":"text","marks":[{"type":"em"}]}]}]}]},{"type":"paragraph","marks":[{"type":"indentation","attrs":{"level":2}}],"content":[{"text":"Several callback functions are invoked in the Qt thread since their purpose is to create or manage QWidget","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph"},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtPage::createPage","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow::onCreateWindow()","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow::onWindowCreated()","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow::onDestroyWindow()","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow::onPageAdded()","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"IQtWindow::onPageRemoved()","type":"text"}]}]}]}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Interface accessor and mutator methods","type":"text"}]},{"type":"paragraph","content":[{"text":"Most interfaces offer, in addition to callback that can be overloaded, some data accessors that are use to query the current state of the functionality handled or modified by the user extension. Accessor methods are usually ","type":"text"},{"text":"const","type":"text","marks":[{"type":"em"}]},{"text":". Those accessors are safe to be called in any thread. However, when using those accessors outside of the simulation thread, the values obtained might rapidly become stale and no longer accurate. So, calls to several accessors in a UI thread might result in mutually incoherent values.","type":"text"}]},{"type":"paragraph","content":[{"text":"Mutators are methods that will change the internal data of the extension, or that request an operation to be performed. It is generally not safe to call mutators outside of the simulation thread, except where specially indicated in the Interface documentation.","type":"text"}]},{"type":"paragraph","content":[{"text":"It is highly recommended that extension developers make there own mutators as thread safe as possible by delaying the operation until the next application update, or by using thread synchronisation techniques. ","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Extension fields","type":"text"}]},{"type":"paragraph","content":[{"text":"Inputs, Outputs and Parameters should be treated as accesors : their values can be read at any time, in any thread. Inputs and Parameters should also be treated as mutators, their value should only be set in the simulation thread.","type":"text"}]},{"type":"panel","attrs":{"panelType":"error"},"content":[{"type":"paragraph","content":[{"text":"Observers on Inputs or Parameters are the main reason problem occurs while setting values to inputs or parameters. If an operation is triggered immediately by an observer, it will be executed in the same thread where the field was modified. Observers can be made a lot safer by setting a flag when triggered, and the operation needed is performed at the next simulation update (in the simulation thread).","type":"text"}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"panel","attrs":{"panelType":"error"},"content":[{"type":"paragraph","content":[{"text":"IExtensoin::onStateSave()","type":"text","marks":[{"type":"strong"},{"type":"em"}]},{"text":" will be called in a worker thread, for performance optimization. No values should be changed, nor can any other extension be modified during that callback.","type":"text"}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"IObject specific","type":"text"}]},{"type":"paragraph","content":[{"text":"IObject","type":"text","marks":[{"type":"em"}]},{"text":" is simply a ","type":"text"},{"text":"IExtension","type":"text","marks":[{"type":"em"}]},{"text":" that can have child extensions. Its callback methods follows the general rules: they are called in the simulation thread.","type":"text"}]},{"type":"paragraph","content":[{"text":"There are two special methods ","type":"text"},{"text":"IObject::add()","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"IObject::remove()","type":"text","marks":[{"type":"em"}]},{"text":". Those methods are used to add or remove child extensions and may be delayed. The operation cannot be performed immediately while the simulator modules are updated or if it is requested from another thread than the simulation thread. In that case, the operation will be performed at the next simulation update, in the simulation thread. Those method are thus safe to be called anytime.","type":"text"}]},{"type":"panel","attrs":{"panelType":"error"},"content":[{"type":"paragraph","content":[{"text":"Since ","type":"text"},{"text":"IObject::add()","type":"text","marks":[{"type":"em"}]},{"text":" is asynchronous, the callback ","type":"text"},{"text":"IObject::isCompatible()","type":"text","marks":[{"type":"strong"},{"type":"em"}]},{"text":" might be called on any thread. It will be called to make sure that the actual adding operation is possible. Thus, ","type":"text"},{"text":"isCompatible()","type":"text","marks":[{"type":"em"}]},{"text":" will be called in the same thread that requests the addition. Only type checking should be performed in this callback.","type":"text"}]}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"ISimulatorModule specific","type":"text"}]},{"type":"paragraph","content":[{"text":"ISimulatorModule is also a IExtension, and its purpose is to power the simulation. Its callback methods follows the general rules: they are called in the simulation thread.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"VxApplication thread safety guidelines","type":"text"}]},{"type":"paragraph","content":[{"text":"The application is a not an extension, but it follows the same general rules: accessors can be used in any thread, but mutators should only be called in the simulation thread. ","type":"text"}]},{"type":"paragraph","content":[{"text":"Obviously, the method ","type":"text"},{"text":"VxApplication::update()","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"VxApplication::run()","type":"text","marks":[{"type":"em"}]},{"text":" are special : the simulation thread is defined by being the thread where ","type":"text"},{"text":"update()","type":"text","marks":[{"type":"em"}]},{"text":" or ","type":"text"},{"text":"run()","type":"text","marks":[{"type":"em"}]},{"text":" is called. The only reason to call those methods is to manage your own main loop, instead of using SimApp.","type":"text"}]},{"type":"panel","attrs":{"panelType":"error"},"content":[{"type":"paragraph","content":[{"text":"Most mutators of ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":" should not be called during the update process, ","type":"text"},{"text":"onPreUpdate()","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"onUpdate()","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"onPostUpdate()","type":"text","marks":[{"type":"em"}]},{"text":" of modules, unless when the documentation specifies that they are asynchronous and thread safe. In that case, they can be called anytime.","type":"text"}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Application context","type":"text"}]},{"type":"paragraph","content":[{"text":"All extensions that need to access global feature should do it through the application context. All methods of the ","type":"text"},{"text":"ApplicationContext","type":"text","marks":[{"type":"em"}]},{"text":" are thread safe and can be called anytime. The managers available from the application context are also thread safe and can be used anytime.","type":"text"}]},{"type":"paragraph","content":[{"text":"In addition, the application context offers the possibility of telling the ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":" to execute a functor in the simulation thread. The method ","type":"text"},{"text":"VxSim::ApplicationContext::executeLater","type":"text","marks":[{"type":"strong"},{"type":"em"}]},{"text":" takes a functor of signature ","type":"text"},{"text":"void(void)","type":"text","marks":[{"type":"em"}]},{"text":" and will execute it when it is safe to do so: in the simulation thread, either just before or just after all the modules are updated. The given functor is garanteed to be executed in the simulation thread. The relative order between different ","type":"text"},{"text":"executeLater","type":"text","marks":[{"type":"em"}]},{"text":" functors is respected : they are executed in the order they are received by ","type":"text"},{"text":"VxApplication","type":"text","marks":[{"type":"em"}]},{"text":", but keep in mind that several threads can add functors simultaneously.","type":"text"}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"paragraph","content":[{"type":"hardBreak"}]},{"type":"paragraph","marks":[{"type":"alignment","attrs":{"align":"end"}}],"content":[{"type":"hardBreak"},{"text":"Template Design Document Revision v1.2 ","type":"text","marks":[{"type":"em"}]}]}],"version":1}

Browser not supported