[cvs] [Wiki] changed: SyncRoadMap

Karsten Fourmont karsten at horde.org
Thu Sep 22 13:08:57 PDT 2005


karsten  Thu, 22 Sep 2005 13:08:57 -0700

Modified page: http://wiki.horde.org/SyncRoadMap
New Revision:  1.2
Change log:  created new todo list

@@ -1,11 +1,26 @@
 + Horde Syncing Roadmap
-
-//This is out of date! Karsten, anyone who can update/maintain it, it'd be appreciated.//
 
 [[toc]]
 
-++ Protocol Issues
+++ Things that need to be worked on
+
++++ Bugs/Limitations
+
+* The client cannot split data in multiple messages or deal with such splits from the client
+* Synthesis support has to be completed for tasks/calendar/address book
+* History retrival has to be fixed to narrow results to meaningful entries
+* The various vcard/vcalendar import/export functions really need some work. Recurring events are not dealt with at all yet.
+
++++ 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)
+* Proper conflict resolution. current policy is: client wins. (As the client send it changes first.)
+* Aligning Client and Server categories
+* Fancy features like 'delete old entries from client calendar/todo list' etc. to save space on client.
+
+++ Other stuff:
++++ Protocol Issues
 
 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!
 
 Otherwise mail the offending xml and/or logs to the list. I'll have a look at it.
@@ -15,9 +30,9 @@
 Make sure to modify the <cred>...</cred> part in the !SyncML header if it exists. It contains your username and password.
 
 I'll try to come up with a brief "how to help with debugging" and add it to the installation docs. Otherwise we might get lots of "just installed the horde rpm and !SyncML doesn't work with my XXYY phone! pls hlp!!!! I'm new to linux!!!!!" messages :-)
 
-++ Data Issues
++++ Data Issues
 
 The second main area where I expect problems are the various implementations of the text/x-vcalendar,vcard,... formats flying around. Basically something like
 
 <code>
@@ -35,9 +50,9 @@
 
 Right now as I'm writing this, I've noticed Jan creating a framework/iCalendar/tests/charset1.phpt test file.  Excellent!
 
 
-++ Code Issues
++++ Code Issues
 
 Of course the !SyncML code is far from being finished. Here are a few things that need work besides the stuff directly coming fomr I or II. (relevant modules are mentioned in brackets)
 
 # refactoring of current codebase (!SyncML)
@@ -65,7 +80,7 @@
     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 manu
 ally 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
++++ 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.


More information about the cvs mailing list