[cvs] [Wiki] changed: SyncMLRoadmap

[Jan Schneider]

jan  Fri, 13 Jun 2008 19:58:55 -0400

Modified page: http://wiki.horde.org/SyncMLRoadmap
New Revision:  1.31
Change log:  A few updates

@@ -11,14 +11,13 @@

  +++ Bugs Limitation in Horde Apps
  These bugs are not directly in the SyncML module but in the various  
Horde applications that store the data
  * Kronolith can't properly deal with more complex recurring events
-* Turba can currently sync only the default data source due to a bug  
in the way it stores its history

  +++ 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.)
+* Allow more customizations which resources calendars/tasklists  
should be synced. This has already been implemented for address books.
+* Proper conflict resolution. current policy is: client wins. (As the  
client send it changes first.) (I think this has been changed to:  
create duplicate)
  * Fancy features like 'delete old entries from client calendar/todo  
list' etc. to save space on client.

  ++ Other stuff:

@@ -30,49 +29,44 @@
  ++ 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.
+You'll have a lot of entries in the {{syncml_*}} database tables that  
you can empty to try a fresh start. Users can also delete all or  
individual synchronization session from their Horde preferences. It is  
also useful to clear out the Horde log file 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!
+The XML files in {{/tmp/sync/}}, the Horde log file and the PHP error  
log should be helpful. If you can provide a patch to make something  
broken work: great!

-Otherwise mail the offending xml and/or logs to the list. I'll have a  
look at it.
+Otherwise mail the offending XML and/or log files to the mailing list.

-As many phones/pdas/whater should be thrown at the code. I'm  
especially interested to see the <devinf> device information section  
that the phones sends in its initial packet. This gets stored in  
/tmp/sync/syncml_client_0.xml when you start with an empty /tmp/sync/  
dir.
+As many phones/PDAs/whatever as possible should be tested against the  
code. We are especially interested to see the {{<devinf>}} device  
information section that the phones sends in its initial packet. This  
gets stored in {{/tmp/sync/client_01.xml}} when you start with an  
empty {{/tmp/sync/}} dir. The parsed result is stored in  
{{/tmp/sync/devinf.txt}}.

-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 :-)
+Make sure to modify the {{<cred>...</cred>}} part in the !SyncML  
header if it exists. It contains your username and password.

  +++ Data Issues

-Another area where I expect problems are the various implementations  
of the text/x-vcalendar,vcard,... formats flying around. Basically  
something like
+Another common area of problems are the various implementations of  
the text/x-vcalendar,vcard,... formats flying around. Basically  
something like

  <code>
  BEGIN:VNOTE
  VERSION:1.1
  BODY: Here's a quick note
  END:VNOTE
  </code>

-!SyncML itself doesn't understand these things: it just passes them  
around between the phone and the external horde api "as they come".
-
-If you have tricky stuff like recurring events, inline photos or  
other exotic data in the file (or got them "treated" by Outlook),  
horde or your phone might quickly get a hickup. So we need to test as  
many of these formats as we can get our hands on.
-
-This is more of a general horde issue than about !SyncML. You can  
test the behaviour by trying to import/export files with this  
ical/vcard data into kronolith/nag/turba using their respective  
import/export menu entries.  That should use the same codebase.
+!SyncML itself doesn't understand these things: it just passes them  
around between the phone and the external Horde API as-is.

-Right now as I'm writing this, I've noticed Jan creating a  
framework/iCalendar/tests/charset1.phpt test file.  Excellent!
+If you have tricky stuff like recurring events, inline photos or  
other exotic data in the file (or got them "treated" by Outlook),  
Horde or your phone might quickly get a hickup. So we need to test as  
many of these formats as we can get our hands on.

+This is more of a general Horde issue than about !SyncML. You can  
test the behavior by trying to import/export files with this  
iCalendar/vCard data into Kronolith/Nag/Turba using their respective  
import/export menu entries.  That should use the same codebase.

  +++ Timestamp and Horde API Issues

-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.