\chapter{Synchronization} This chapter gives brief introduction of synchronization basics as well as how OpenSync works and handles real life synchronization issues.\\ \\ Different synchronization techniques are used nowadays, which have some of the following tasks in common: \begin{itemize} \item Connect \item Get changes \item Conflict resolution \item Multiply changes \item Commit changes \item Disconnect \end{itemize} Those tasks are common for synchronization technique/protocol, but differ in detail, in order to fit the needs for different circumstances and to meet the best efficiency. Such circumstances could be: \begin{itemize} \item Number of synchronization parties. If number of synchronization parties is two, then multiplying of changes is just simple duplication of the change. \item Unidirectional/Bidirectional synchronization. For unidirectional synchronization, no conflict resolution is required for two parties. \item Resource. Depending of the type of data resource, further work is required to get changes. Is the resource able to tell which data changed since the last synchronization, on its own, or is further help/facility required to detect which data changed since the last sync? For example: file systems, databases, or stacked data in a single file. % The following item is still quite awkward. \item Type of data. Is the data in a consistent format and supported by all parties? File synchronization. Is the data inconsistent and does it contain unique information which doesn't allow for a binary compare? Weak compare? Is conversion to a common format for different parties required? \item Protocol. Does the protocol require reading only the latest changes or all changes at once? \item Transport. Are various transport layers involved? Does it need to connect and disconnect in a specified way? Limited bandwidth? For example: Bluetooth, or USB. \end{itemize} There are many different circumstances, which makes meeting all the needs of different ways to synchronize quite comlpicated.\\ % You see, there are many different circumstances which make it quite complicated % to meet all the needs of different ways to synchronize and synchronization % protocols.\\ This is only the tip of the iceberg, since it describes only the synchronization role of the ``Server''. \section{Synchronization Role} The term ``Server'' is quite confusing, especially in the combination of a synchronization protocol which uses a transport protocol based on the \emph{Client}- and \emph{Server}-Model. The most famous example is \emph{SyncML}, which supports, among others, the HTTP and OBEX protocol for transport. You might know \emph{HTTP Server} like the Apache Webserver and \emph{HTTP Client} like the Firefox Webbrowser. In \emph{SyncML} you can have for example: \begin{itemize} \item HTTP Server transport and act as Synchronization Server \item HTTP Client transport and act as Synchronization Server \item HTTP Server transport and act as Synchronization Client \item HTTP Client transport and act as Synchronization Client \end{itemize} Likewise for other transport protocols supported be \emph{SyncML} % the second sentence is awkward OpenSync doesn't care much about the Transport Server/Client role, this is up to the Plugins. There is only a little detail that OpenSync has to care about the plugin, when it is acting in the transport Server role, which is that the plugin has to be initialized all the time so the client can connect. More about this in the Plugin chapter.\\ \\ Unfortunately, in version 0.40, OpenSync only supports the Synchronization Server role. The passive role as Synchronization Client isn't yet implemented, but is on the top of the project agenda. The reason for this is that the current implementation of synchronization tasks/steps mentioned above are currently fixed. As a Synchronization Client, the order and number of this synchronization steps/tasks would differ from the Server role. You can find more about this issue in the Framework Chapter in section Synchronization Role. \section{Slow Sync} Various Synchronization protocols are using the so called \emph{Slow Sync} synchronization technique. This consists of two types of synchronizations, the already mentioned \emph{Slow Sync} and a regular Synchronization (sometimes called \emph{Fast Sync}). The difference between the Slow and the regular (Fast) Sync is that the regular one only transfers changes since the last synchronization. This means, on a regular synchronization, not all entries have to be transfered, or converted. This makes the synchronization quite efficient and very fast. The so called \emph{Slow Sync} intentionally requests all entries, which makes the synchronization a bit slower. Additionally, the Synchronization Framework has to interpret every single entry/change as newly added, since the Framework vanished in advance of the entire mappings and has to compare every single reported entry from each party and find the fitting counterpart. This, and the transferring of all entries, makes the synchronization much slower when compared with the regular (Fast) synchronization. The \emph{Slow Sync} is only used in certain cases to avoid data inconsistence and to keep all the data in sync. \emph{Slow Sync} is emitted in following circumstances: \begin{itemize} \item First/Initial Synchronization \item Party has been reset (same as first sync) \item Party has been synchronized within another environment \item After an aborted/failed synchronization \end{itemize} \section{Object Types} The term \emph{Object Types} is used in OpenSync to describe the type/category of data. Examples of \emph{Object Types} are Contacts, Events, Todos, Notes or plain Data (like the content of a file). It's not limited to PIM Data! Those Object Types processed separately, to make it configurable which Object Type should get synchronized. For example: only synchronize contacts of the mobile, no events, todos nor notes. \section{Formats} The ability to synchronize different Parties which use different formats, makes the OpenSync Framework to a very powerful Synchronization Framework. In OpenSync each Format is associated with one Object Type (see previous chapter). Having this Object Type as common denominator for different formats makes it possible to determine a conversion path between different formats. The conversion path consists of various format converters, which are provided by Format Plugins. For example: two parties should synchronize their contacts (the Object Type). Party A stores the contacts as VCard 3.0 and Party B stores the contacts in some Binary Format. To synchronize the VCard 3.0 and the Random Binary Contact Format, format plugins have to register those formats and provide converters. The Plugins don't have to provide converters for every known Format; often a certain amount of converters to common formats or a common denominator format is enough to create a conversion path between VCard 3.0 to Binary Contact Format. \section{Mappings} If an entry has been changed on one Party, the logical same entry has to be updated on the other parties during synchronization. Different parties often use different ids to identify their entries. So it is necessary to map the logical same entries to each others native id. The combination of those different entries on different parties are called \emph{Mappings}. Those \emph{Mappings} make it possible to determine a conflict if mapped entries got changed on different parties the same time in a different way. \section{Conflicts} So called \emph{Conflicts} appear if at least two entries of the same mapping got changed in a different way. No conflict appears if all entries of the mapping changed the same way. Conflicts have to be handled by the Synchronization Framework to avoid data loss. There are several ways to solve such conflicts. OpenSync provides several different methods for a proper conflict resolution without unintended loss of data. The following conflict resolution methods are supported by the OpenSync Framework: \begin{itemize} \item Solve, means intentionally choosing one of the conflicting entries to solve the conflict. The chosen entry will be multiplied to all parties and will overwrite the other conflicting changes. This also permits the user to configure in advance who is the \emph{Winning} Party, who's changes will always used as the solving change (\emph{master change}) for the conflict. \item Duplicate, will (intentionally) duplicate all changed entries. \item Latest, using the latest changed entry of the conflicting entries. This is only a conflict resolution option if all changes provide enough information within their formats to determine which one was changed most recently. \item Ignoring, (temporarily) the conflict until the next synchronization. Conflicting entries will be read and compared again by the OpenSync Framework on the next synchronization. To avoid inconsistence and data loss. If the entries/changes are equal on the next synchronization the conflict is solved as well. (This conflict resolution requires that the protocol of all parties is able to request single entries, without triggering a "Slow Sync".) \end{itemize} \section{Capabilities} \section{Filter} OpenSync provides initial code for filtering, but it's not yet usable within OpenSync 0.40. Look forward to OpenSync 0.41!