[cvs] [Wiki] changed: SyncRoadMap

[Wiki Guest]

guest [207.172.212.178]  Sun, 16 Oct 2005 15:07:55 -0700

Modified page: http://wiki.horde.org/SyncRoadMap
New Revision:  1.9
Change log:  spelling and wikiwords

@@ -5,12 +5,12 @@
 ++ Things that need to be worked on
 
 +++ Bugs/Limitations
 
-* 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.
-* 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)
@@ -23,12 +23,12 @@
 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.
+* 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)
+* 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:
 +++ Debugging info