Is the "phone" branch ready for merging? It seems that at least the
"initiate slow sync" part still needs some work or cleaning up.
I'd can merge this after fixing the compiler warnings on the current
master later today, if you want.
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 WBXML
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
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
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"
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.