[cvs] [Wiki] changed: SyncRoadMap

Tue Oct 18 01:30:14 PDT 2005

jan  Tue, 18 Oct 2005 01:30:14 -0700

Modified page: http://wiki.horde.org/SyncRoadMap
New Revision:  1.12
Change log:  Revert

@@ -5,23 +5,34 @@
 ++ 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
+* History retrieval has to be fixed to narrow results to meaningful entries
+* sometimes the synthesis clients crashes upon receiving calendar data.
 * The various vcard/vcalendar import/export functions really need some work. Recurring events are not dealt with at all yet.
-* Initial SlowSync of Evens does millions of datatree reads and still takes way too much time. Somethings wrong with that.
-* when server has a matching anhor it will always do a delta sync, even when the client requests a slowsync
+* when server has a matching anchor it will always do a delta sync, even when the client requests a slowsync
+
 +++ 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
+* 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.
+
++++ Code Cleanup
+
+This sections lists stuff that does not directly affects functionality but rather the quality of the code
+
+* better error handling (!SyncML): currently no real error handling is in place.
+* finish refactoring: all horde specific stuff should go into backend.php. The rest of the package should be Horde independent
+* event handling is a big mess: the current major design flaw is that the classes in !SyncML/command are use for parsing the //input// from the client as well as creating the //output// for the client: this results in a ulgy double-usage of the output method: the output method of Status.php illustrates these two functions: first it's automatically called by the event handler in //!SyncML.php// to produce the output in response to a Status element sent from the client. This means producing no output is all. And then it's use to create Status responses as result to other operations (Add, Sync etc.). Here the output method of status is called as well, but this time it should do something very much different: produce an actual "Status" output.
+* each syncml command has a (per message) unique //commandID//. The various output methods take at least the //currentCommandID// and the !ContentHandler as parameters. They return the increased //currentCommandID//. Non of these three is necessary: they should be moved to global variables or (better) a global object dealing with the state of one message (one script run) in contrast to state.php dealing with the state between different messages.
+* Check where's the best place to draw the border between the rpc and syncml package. Currently syncml.php in RPC does some XML parsing (for body and header). This should be moved to Syncml to leave RPC will all the //transfer protocol// stuff and Syncml with all the contents.
+* 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)
+
 
 ++ Other stuff:
-+++ Protocol Issues
++++ 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!
 
 Otherwise mail the offending xml and/or logs to the list. I'll have a look at it.
@@ -33,9 +44,9 @@
 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
 
-The second main area where I expect problems are the various implementations of the text/x-vcalendar,vcard,... formats flying around. Basically something like
+Another area where I expect problems are the various implementations of the text/x-vcalendar,vcard,... formats flying around. Basically something like
 
 <code>
 BEGIN:VNOTE
 VERSION:1.1
@@ -51,31 +62,11 @@
 
 Right now as I'm writing this, I've noticed Jan creating a framework/iCalendar/tests/charset1.phpt test file.  Excellent!
 
 
-+++ Code Issues
++++ Timestamp and Horde API 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)
-
-The current codebase is somewhat confusing and hard to deal with. I'll try to refactor it to make it easier for other people to jump in. Any help is appreciated. Especially suggestions about the best way to parse XML subtrees into PHP objects.
-
-# better error handling (!SyncML): currently no real error handling is in place.
-
-# Turba contacts support (Turba): I haven't looked at it yet. it might just work or not. Depends on whether VCARD in turba support is fine or not. You can just try to sync vcard data and see if you run into problems.
-
-# better tasks import(Nag): currently nag imports only task name, description and priority. See the two @TODO lines in nag/lib/api.php. This should be extended to import the full info (alarm, due dates etc.). Export should be checked as well.
-
-# Collision handling: (!SyncML, Nag, Mnemo, Kronolith, Turba). My idea for collision handling is: while running !SyncML: keep the existing entry and add the collision as a new one somehow marked as "collision" of entry guid #xxx. (stored in !DataTree). Then kronolith etc. should have a page to display the colliding items side by side. There you can select which one to keep (and/or maybe edit manually). The "losing" entry gets deleted, which is then automatically synced as any normal delete during the next sync session. Should be rather straightforward to implement and requires minimal effords on the !SyncML side.
-
-# Get support for additional Sync Types (!SyncML). Currently only !SlowSync and !TwoWaySync are supported. These are the only two that are mandatory in !SyncML and the only two my phone supports. Don't know if we need the others. Some code is already there.
-
-# Make use of devinf information (!SyncML): In the inital !SyncML packets both sides exchange a <devinf> block with information about device capabilites. This info should be stored and used.
-
-# Horde api enhancements (HORDE API):
-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)
+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:
     1) the clients sends its changes to the server
     2) the server sends its changes to the client.
@@ -84,4 +75,5 @@
 
 +++ 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.
+
