## 5 SARA Data Model
### Events  
So far it has been presented how to encode the information that forms the _Sessions_. Now, it is time to expose the data model that allows the exchange of information between the different services of the architecture. The main entity used for this is an _Event_ and its details can be found in Figure 9.  
As can be seen in Figure 9 two fields are known for each _Event_: the user who launched it (i.e., the client id) and the target session (the _Session_ to which the sender user is connected to). The type property is used to easily distinguish the type of event when decoding it. For the moment, there are two different types of _Events_: _Interaction_ events and _Information_ events.  
On one hand, the _interaction_ group encapsulates actions performed on a digital element, such as clicks (which would be a common interpretation of taps and touches) or drag. On the other hand, the _information_ group includes events that update the information of the session or the connections, hence the name.  
* When a client application wants to connect to the system, a _NewUserConnection_ event must be generated. In this event the user that will be connected must be specified, as well as what we call a _Connection Method_. As will be explained later, the system permit the network connection to be performed using different protocols such as TCP, UDP, WebSockets and MQTT. Once the client has connected with the system, it can be easily known which of these protocols was used to establish the connection. However, in order to keep the data model clear, it has been decided to indicate this information within the event itself. At this moment, her connection information has been stored, but has not been connected to any _Session_ yet. In order to do this, a _ConnectToSession_ event is required.  
Figure 9: Data model of the Events handled by the system.  
* A _ConnectToSession_ event must contain the identifier of the session to which the user is going to connect, the user itself and a _status reception format_. The reason of the last field is closely related to another of the types of information events, the _SetSessionState_.
* the _SetSessionState_ event is used to completely replace the state of a session or to start it for the first time. As it can be seen, it has a _format_ field and a _new session state_ one. In order to maximize compatibility with as many platforms as possible, the system allows coding the state of a session using different formats. Some of them, such as OBJ or COLLADA, are the most popular on all platforms. However, the use of a custom JSON format is introduced here with the aim of allowing greater clarity to the exchange of events as well as greater flexibility. The idea is to export the status of the sessions (i.e., the nodes structure) to one of these formats and to encode the result as a base64 string. With this differentiation, different users may receive the same _SessionStatus_ by means of different formats. It can be argued that this type of communication is not the most efficient. In future SARA implementations, the entire data model could be encoded as flat bytes, which would reduce the amount of information moved within the system (since the JSON format introduces redundant characters) and the communication times.
* Finally, as opposed to the _SetSessionState_ which replaces the old state of a session with a new one, the _IncrementalUpdate_ event is used to update specific properties of the nodes such as the position or the rotation. To do so, the id of the target node is required, as well as the path to the property. Let's take as an example an update event for the position of a node (which would be thrown, for example, when the node gets moved due to some kind of logic). The _property_path_ would have a value of _\"\(transform\).position\"_ and the _new_value_ would store the new state of that property (e.g., an array like [1.0, 0.0, 0.0]). By using this event, selective changes can be made without requiring to override the whole state of the _Session_.