2:09 a.m.
Hello!
I just pushed some changes into activesyncd master which (finally) allow
running the SyncEvolution backend and sync testing. Sorry for the delay.
Instructions in the README, quoted below.
In contrast to what I said in the folder thread, the default database is
enough for testing because I added some code to the backend which
ensures that that database is used for testing, instead of a named
database that the test framework normally would use.
I am seeing some issues with sync key handling. In some cases, the
activesyncd debug output shows random characters. That looks very much
like an invalid memory access.
I had a brief look into eas_sync_handler_get_items(), but only found a
memory leak:
sync_key_in = g_strdup("0");
has no corresponding g_free().
Is suspect that part of the problem is that Client::eas_event::Source
needs to "simulate" access by two different clients. Both use the
ActiveSync account defined by
~/.config/syncevolution/client-test/peers/target-config/config.ini
so essentially this looks to the Exchange server like one client.
Is it absolutely necessary that the account ID is a valid email address?
If not, then I could create two accounts in gconf, one called
SyncEvolution_Test_1 and another SyncEvolution_Test_2, then switch
between them as needed. Both accounts would use exactly the same
username, password and server URL.
One test which should already work but fails (even with the time zone
fix, commit cb4046) is the Client::Source::eas_event::testImport test.
It fails with:
error 100 returned from wbxml_conv_xml2wbxml_run
See Client_Source_eas_event_testImport.log after running the test.
I have libwbxml2-0.11.beta6-7.1.i586 installed in MeeGo.
-----------------------------------------
Backend Testing
===============
Configure "local" testing (backend is covered, no syncing involved):
./syncevolution --configure username=<email adddress identifying the
account> \
--template SyncEvolution target-config@client-test
On MeeGo:
- install syncevolution-test and syncevolution-synccompare
- create an empty directory, enter it
- copy /usr/share/doc/syncevolution/testcases
- CLIENT_TEST_UNIQUE_UID=1 \
CLIENT_TEST_SERVER=exchange \
client-test Client::Source::eas_event
When compiling SyncEvolution:
- enter the src directory
- CLIENT_TEST_UNIQUE_UID=1 \
CLIENT_TEST_SERVER=exchange \
PATH=.:$PATH \
./client-test Client::Source::eas_event
CLIENT_TEST_UNIQUE_UID is necessary to avoid a UID conflict in a
simple-minded insertion test. The proper solution is to add an "item
exists" error to activesyncd and handle that in
ActiveSyncSource::insertItem().
The test data that is used for testImport is in:
testcases/eds_event.ics
This data was meant for Evolution. Because it is standard iCalendar 2.0,
it is a suitable starting point for Exchange. If it turns out that this
data doesn't work with Exchange, then a simplified/adapter version of
the file can be put into:
testcases/eds_event.ics.exchange.tem
Sync Testing
============
- Configure target-config@exchange with source 'calendar'.
- Create two sync configs:
syncevolution --configure username= password= \
syncURL=local://@exchange uri=calendar \
backend=evolution-calendar \
--template SyncEvolution_Client exchange_1@client-test-1
eds_event
syncevolution --configure username= password= \
syncURL=local://@exchange uri=calendar \
backend=evolution-calendar \
--template SyncEvolution_Client exchange_2@client-test-2
eds_event
- Create calendars named as follows in Evolution:
SyncEvolution_Test_eds_event_1
SyncEvolution_Test_eds_event_2
- run test (see above for invoking client-test and setting up
"testcases"):
CLIENT_TEST_UNIQUE_UID=1 CLIENT_TEST_SERVER=exchange \
client-test Client::Sync::eds_event::testCopy
---------------------------------------------------------
--
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.