[cvs] [Wiki] changed: SyncRoadMap

[Karsten Fourmont]

karsten  Sat, 28 Oct 2006 14:59:05 -0700

Modified page: http://wiki.horde.org/SyncRoadMap
New Revision:  1.26
Change log:  update to reflect current development status

@@ -1,31 +1,20 @@
-+ Horde Syncing Roadmap
++ Horde SyncML Roadmap
  
  [[toc]]
  
  ++ Things that need to be worked on
  
  +++ Bugs/Limitations
  
-* When doing !SlowSync with no phone data, the phone may never sent a <sync>. Horde only creates it output in respond to this sync so nothing is send then.
-* sometimes the synthesis clients crashes upon receiving calendar data.
-* iPaq Sync with Sync4j Connector: Kronolith all day events show up on wrong days on the PDA: An all day event in   Kronolith for let's say the 19th of december 2005 has a start time of  00:00 on the 19th and ends on 00:00 on the 20th.  This event ends up on the PDA with an end time of 23:59 on the 20th.
-* Nokia: one hour offsets when syncing calendar entries.
+* 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.
+* 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.
  
  +++ Possible Extensions
  
  * Allow customizations which calendars/addressbooks should be synced. Maybe allow merging of more than one data source (think of private and shared calendar) (Apple has a really cool feature for multiple calendars in a palm device: Each category in the palm is one subscribed calendar in iCal. Maybe a feature like this would be great to have overlayed/group calendards)
  * Proper conflict resolution. current policy is: client wins. (As the client send it changes first.)
-* Aligning Client and Server categories (work started on that. Currently visible only for P800/P900)
  * Fancy features like 'delete old entries from client calendar/todo list' etc. to save space on client.
-* Palm: Mapping all-day events to a time range (e.g. 8am-23pm). I think palm does not know/handle an all-day event flag and therefore the icalendar/calendar data is modifed when resynced. (Committed a patch to this)
-
-+++ Code Cleanup
-
-This sections lists stuff that does not directly affects functionality but rather the quality of the code
-
-* create meaningful phpdoc source code documentation
-* better error handling (!SyncML): currently no real error handling is in place.
  
  ++ Other stuff:
  
  +++ Testing Suite
@@ -73,9 +62,5 @@
      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).
-
-+++ Testing Suite
-
-Nobody has access to all the !SyncML clients all the time. So there's a always the risk that you supply a fancy enhancement patch that works fine for you but breaks down everything for everyone else. So it would be great to have a "testing suite" (in JUNIT terms) which simulates sync runs for all supported phones. (Maybe done by sending specifically crafted XML files based on the logging data of various phones and checking the results). Before a commit of a new patch a test run is done with this suite to ensure it doesn't break things up. Just an idea (dream) for now, suggestions how this could be done are welcome.