[cvs] [Wiki] changed: SyncMLRoadmap

[Karsten Fourmont]

karsten  Sat, 13 Jan 2007 06:45:50 -0800

Modified page: http://wiki.horde.org/SyncMLRoadmap
New Revision:  1.29
Change log:  moved development stuff from SyncHowTo

@@ -20,8 +20,18 @@
  +++ Testing Suite
  The !SyncML Conformance Test Suite can be downloaded from sourceforge: http://sourceforge.net/projects/oma-scts/
  
  SyncMLConformanceTestSuite shows which test we currently pass or fail.
+
+++ Cleaning up when testing
+
+You can clear all session files (assuming the default backend) with {{rm -f /tmp/sess_*}}.
+
+You'll have a lot of entries in the datatree with a group_uid of 'horde.history'. You will lose information from more than syncing by clearing them out, but you can do so. It is also useful to clear out horde.log and /tmp/sync to get a better feel for what is from the current sync attempt and what is not.
+
+++ Links
+* SyncMLDevicesFileFormats
+* SyncMLCreateTestCases: information on SyncML test cases
  
  +++ Debugging info
  
  Once the current code makes it to CVS people should give it a try and check if it works. If not, the xml in /tmp/sync/, the horde log and the php error log should be helpful. If you can provide a patch to make it work: great!
@@ -62,5 +72,15 @@
      1) the clients sends its changes to the server
      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).
+
+++ Using a Palm simulator to test the Synthesis client
+
+# Download Palm simulator (for version 5.4) from http://www.palmos.com/dev/tools/simulator/ (free registration required).
+# Unzip somewhere, start debug/!PalmSim_54_dbg.exe, select a suitable ROM (included in debug dir)
+# Right-click on Simulator and click Settings > Communications > Redirect !SocketLib Calls to Host TCP/IP
+# Download and unzip synthesis client for !PalmOS from http://www.synthesis.ch/
+# Install simulator by dragging the enclosed .rpc file into the simulator window.
+# Start & configure the Synthesis client. Start a sync run.
+