I've looked at the code. Some comments:
Server Alerted Sync: SAN generation
ContentType in the 'Get' command during the SAN should be XML or
of SAN Notification.
Why that? Perhaps I misunderstand the code, but doesn't it ensure that
the content type for the SAN message is
TransportAgent::m_contentTypeServerAlertedNotificationDS and *not* XML
It means the request sent for SAN must have a san content type but when you use
"Get" to pull response you must use XML/WBXML.
This is found by Nokia phone and it is reasonable.
FileSyncSource: use x-vcalendar instead of x-calendar
This changes user-visible behavior, and not just in the FileSyncSource,
doesn't it? I agree that x-vcalendar is the better choice, but
x-calendar should still be accepted for users who have it in their
Yes, I just thought this was a typo.
Agree, anyway it breaks FileSyncSource with vcal2.1, I believe. No time to check today, I
may come out a patch for FileSyncSource later.
Join/dejoin Mutiple SyncSources, MB#4611
Can you move the escape code for the new virtual backend's
evolutionsource property into util.cpp? It's likely that we'll also need
it for multiple syncURLs.
+ "If the backend is a virtual data source, \n"
+ "this field points a comma seperated list of \n"
+ "sub datasources actually used for syncing.\n"
+ "If your sub datastore has comma in name, you\n"
+ "can separated by preceding it with '\\' \n"
Extra white space - evil! ;-) Spelling improvement:
"If the backend is a virtual data source,\n"
"this field must contain a comma separated list of\n"
"sub datasources actually used to store data.\n"
"If your sub datasource has a comma in its name, you\n"
"must prevent that comma from being mistaken as the\n"
"separator by preceding it with a backslash, like this:\n"
" evolutionsource = Source1PartA\,PartB, Source2\\Backslash\n"