\documentclass{article}
\usepackage{ulem}
\usepackage{graphicx}
\usepackage{hyperref}
\pagestyle{headings}
\begin{document}
\part{Horde SyncML Roadmap}
\section{Things that need to be worked on}
\subsection{Bugs/Limitations in <a href="https://wiki.horde.org/SyncML">SyncML</a>}
\begin{itemize}
\item Splitting a long data entry (like a 60k memo) into multiple messages is not supported when sending data to the client. However it is supported when the client sends split data.


\item When doing a SlowSync, the Server could handle a replace request by the client better than just converting it into an add: the server should check if this client sent element exists on the server. If so: replace, otherwise add.


\end{itemize}
\subsection{Bugs Limitation in Horde Apps}
These bugs are not directly in the <a href="https://wiki.horde.org/SyncML">SyncML</a> module but in the various Horde applications that store the data

\begin{itemize}
\item Kronolith can't properly deal with more complex recurring events


\end{itemize}
\subsection{Possible Extensions}
\begin{itemize}
\item Allow more customizations which resources calendars/tasklists should be synced. This has already been implemented for address books.


\item Proper conflict resolution. current policy is: client wins. (As the client send it changes first.) (I think this has been changed to: create duplicate)


\item Fancy features like 'delete old entries from client calendar/todo list' etc. to save space on client.


\end{itemize}
\section{Other stuff:}
\subsection{Testing Suite}
The SyncML Conformance Test Suite can be downloaded from sourceforge: <a href="http://sourceforge.net/projects/oma-scts/">http://sourceforge.net/projects/oma-scts/</a>

<a href="https://wiki.horde.org/SyncML/ConformanceTestSuite">SyncML/ConformanceTestSuite</a> shows which test we currently pass or fail.

\section{Cleaning up when testing}
You can clear all session files (assuming the default backend) with \texttt{rm -f /tmp/sess\_*}.

You'll have a lot of entries in the \texttt{syncml\_*} database tables that you can empty to try a fresh start. Users can also delete all or individual synchronization session from their Horde preferences. It is also useful to clear out the Horde log file and \texttt{/tmp/sync/} to get a better feel for what is from the current sync attempt and what is not.

\section{Links}
\begin{itemize}
\item <a href="https://wiki.horde.org/SyncML/DevicesFileFormats">SyncML/DevicesFileFormats</a>


\item <a href="https://wiki.horde.org/SyncMLCreateTestCases">SyncMLCreateTestCases</a>: information on <a href="https://wiki.horde.org/SyncML">SyncML</a> test cases


\end{itemize}
\subsection{Debugging info}
The XML files in \texttt{/tmp/sync/}, the Horde log file and the PHP error log should be helpful. If you can provide a patch to make something broken work: great!

Otherwise mail the offending XML and/or log files to the mailing list.

As many phones/PDAs/whatever as possible should be tested against the code. We are especially interested to see the \texttt{<devinf>} device information section that the phones sends in its initial packet. This gets stored in \texttt{/tmp/sync/client\_01.xml} when you start with an empty \texttt{/tmp/sync/} dir. The parsed result is stored in \texttt{/tmp/sync/devinf.txt}.

Make sure to modify the \texttt{<cred>...</cred>} part in the SyncML header if it exists. It contains your username and password.

\subsection{Data Issues}
Another common area of problems are the various implementations of the text/x-vcalendar,vcard,... formats flying around. Basically something like

<pre><code>
BEGIN:VNOTE
VERSION:1.1
BODY: Here's a quick note
END:VNOTE
</code></pre>
SyncML itself doesn't understand these things: it just passes them around between the phone and the external Horde API as-is.

If you have tricky stuff like recurring events, inline photos or other exotic data in the file (or got them "treated" by Outlook), Horde or your phone might quickly get a hickup. So we need to test as many of these formats as we can get our hands on.

This is more of a general Horde issue than about SyncML. You can test the behavior by trying to import/export files with this iCalendar/vCard data into Kronolith/Nag/Turba using their respective import/export menu entries.  That should use the same codebase.

\subsection{Timestamp and Horde API Issues}
a) currently the horde api only supports listBy(\$action, \$ts) to retrieve \$actions since timestamp \$ts. The SyncML protocol requires that the ending timestamp of the sync timeframe to be exchanged \_before\_ the actual syncing starts. So we need an additional parameter: listby(\$action,\$ts,\$ts\_end)

b) the SyncML works as follows:<br />
1) the clients sends its changes to the server<br />
2) the server sends its changes to the client.

so when in step 2), the horde api is called with a request like "give me all changes in horde since the last sync", you get the changes induced by the client in step 1) as well. You have to somehow "tag" them to avoid echoing (and thus duplicatinging) them back to the client. Simply storing the guids in the session is not sufficient: the changes are made \_after\_ the end timestamp (see a)) of the current sync so you'll dupe them in the next sync. My current implementation deals with this as follows: directly after a client induced change is done in horde, state.php's gettsforAction is called to find out the biggest=latest ts for the given guid. If the horde api would provide me with this info directly (maybe just store it in a static var and provide a getLastTS() method in Driver), that would be great and eliminate costly and redundant DataTree calls. Similar in listBy where you get a list of guids but still need to retrieve the latest History timestamps for these guids manually using the DataTree so you can check out if the changes are a result of a client request or not. If listBy would return an assoc array \$guid->ts that would help a lot (and solve a) as well).

\section{Using a Palm simulator to test the Synthesis client}
\begin{itemize}
\item Download Palm simulator (for version 5.4) from <a href="http://www.palmos.com/dev/tools/simulator/">http://www.palmos.com/dev/tools/simulator/</a> (free registration required).


\item Unzip somewhere, start debug/!PalmSim\_54\_dbg.exe, select a suitable ROM (included in debug dir)


\item Right-click on Simulator and click Settings > Communications > Redirect SocketLib Calls to Host TCP/IP


\item Download and unzip synthesis client for PalmOS from <a href="http://www.synthesis.ch/">http://www.synthesis.ch/</a>


\item Install simulator by dragging the enclosed .rpc file into the simulator window.


\item Start \& configure the Synthesis client. Start a sync run.


\end{itemize}
\end{document}
