\section{Implementation Considerations}
\label{sec:impl}
\subsection{Globally unique IDs}
When a user updates a morph on his page, the changes have to be sent to the accordant morph on the other users' pages. Therefore, globally unique IDs are assigned to all new morphs so that a morph can be unambiguously identified on each page. We extended the ID generation in Lively to avoid conflicts (i.e. same ID generated on different clients for different morphs) by scoping all IDs to the current user: Instead of generating IDs like \verb+1234:Morph+, \verb+lively.data.Wrapper#setId+ add the user ID resulting in \verb+user541234:Morph+\footnote{a colon as separator couldn't be used here since some existing code relied on the class name after the first colon}.

\subsection{Object (de)serialization}
As described in section \ref{sub:client_architecture}, we are intercepting relevant morph methods to listen to changes. Arguments are saved in command objects that have to be serialized when sending to the server. Especially when it comes to serializing whole morphs, i.e. for \verb+Morph#addMorph+ synchronization, a smarter serialization approach is necessary to handle circular references and already existing objects. \cite{dannert:webcards} provides a Relaxer and Restorer class for (de)serialize Lively morphs that could be easily adopted for our use case: When adding a new morph (which might contain sub morphs, for example), all references to other morphs are only saved by their IDs so that a quite flat JSON structure is generated. Other clients can then deserialize this structure and restore all previous relationships.

\subsection{WebSockets}
\emph{Websockets} are a fully bidirectional and slim protocol from the upcoming \emph{HTML5} standard. The decision for \emph{Websockets} as the protocol between the client and the server was taken, because of the need for nearly realtime bidirectional communication. There is a japanese website\footnote{\url{http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html}} on which everyone can test the speed difference between \emph{Websockets} and XML HTTP requests (\emph{Ajax}). With the latest \emph{Google Chrome} browser the benchmark of the website shows that \emph{WebSockets} are nearly 40 times faster than the \emph{Ajax} requests.