\section{Approach}
\label{sec:approach}
This section explains our approach for implementing basic collaboration features into the Lively kernel. For this purpose a framework is needed that allows synchronizing changes of one user with others.

A first question that have to be discussed is the level on which changes should be observed and recorded. In browser environments, there are at least three potentially suitable levels: (a) Events from input devices (mouse, keyboard), (b) changes in DOM structure or (c) calls to the JavaScript API. Propagating mouse and keyboard events from one users to another (a) has the drawback that button clicks with non-local side effects (e.g. deleting a record on a server) would be called twice. Synchronizing DOM changes like a newly added SVG node (b) would create a common view on the currently opened page, but doesn't execute related JavaScript code: A new button is visible to all users, but no action handlers is assigned to the button since this requires JavaScript. The most promising solution to our problem is to listen to basic Lively API calls (c) (like \verb+TextMorph#setTextString+, \verb+Morph#setPosition+ or \verb+Morph#addMorph+) and propagate them to other clients. This way, the JavaScript object state keeps synchronized while the propagated method calls care about updating the underlying DOM.

To record the method calls made to the Lively API, we decided for a command-based interaction (Figure \ref{fig:command_sequence}): When a method is called, a command is created locally in the client encapsulating all the information needed to execute and undo the method later on other clients. This information includes particularly the arguments of the called function and the current state for undoing (e.g. a call to \verb+Morph#setPosition+ saves the new and the old position). After having created the command, it is executed locally to ensure fast feedback to the user (optimistic approach). Then the command object is serialized and send to the server so that other clients get informed about the change. The server assigns an ascending id to the command and puts it at the end of the global command queue which is solely managed on server side. The id of the command defines the order of the command queue, and clients have to assure that commands are executed in the given order. Finally, the command is sent to all clients, who arranges it in their local command queue and execute it according to the command's id. The client which created the command in the first place doesn't execute the command a second time, but the assigned id have to be checked with the order in its local command queue. If other commands have been received in the meantime, the command has to be undone and wait its turn.

\begin{figure}[h]
\begin{center}
\includegraphics[width=0.8\textwidth]{resources/petri_call.pdf}
\caption{Command life cycle using the example of an user who is typing text}
\label{fig:command_sequence}
\end{center}
\end{figure}

During a collaboration session, all incidental commands are stored on the server side. As soon as a user presses Lively's built-in save button, a new milestone is created (which just references current command's id). When a new user joins an existing session, he receives a unique user id and a list of all commands that have been created since the last milestone. To implement a playback/ time-slider feature as mentioned in the introduction, a user could switch between milestones (and the accordant commands belonging to this milestones) and see all visual changes that have been made in the meantime.
