I've finally managed to get everything to work, I think. Patrick, if you want to see my changes, you can download a tarball from http://people.debian.org/~ovek/harmattan/syncevolution_1.2.99.4-1.tar.gz It contains the git tree I work from. Most of the build system patches are probably in the FREMANTLE-1-2-99-3 branch. I could perhaps make a list if you want, but perhaps you want to look for yourself.
--- Notes for Maemo Fremantle: The package should be available from extras-devel, or from http://people.debian.org/~ovek/maemo/ The changelog is: * Fixes to Maemo calendar backend. - Updated to use SyncEvolution's new support for automatically detecting whether to sync notes in text/calendar or in text/plain format. (Previously, the default was to always sync as text/plain, which would lose any metadata.) - Return ITEM_REPLACED instead of ITEM_MERGED if the calendar-backend detects conflicts. - Implemented SyncSourceLogging::getDescription(), to make it easier for users to find out which entry is the problem if something goes wrong. - In listAllItems(), read entries from database one by one, instead of loading everything into RAM all at once. This may be a little slower, but it would also reduce resident memory requirements for large calendars. Since RAM is a precious resource on the N900, this is hopefully a net win. * Updated packaging for new SyncEvolution build system. Build-Depend on automake 1.10, libtool, libboost1.42-dev, and libcppunit-dev. * Although I've tried to use the newest tools available in the Fremantle repositories, they're still a bit old for the SyncEvolution build system, and I had to patch the build system a fair bit for it to work. * Also patched the SyncEvolution code itself to work with the fairly old compiler (gcc 4.2). If people wish, the backend could be sped up by moving away from TrackingSyncSource and use a timestamp-based approach (like KCalExtended does) instead. A drawback of such an approach would be that you should not change the calendar while a sync is in progress. I already wrote some code for this, but didn't finish it since I wasn't sure it was worth it. --- Notes for MeeGo Harmattan: The package should be available from http://people.debian.org/~ovek/harmattan/ The changelog is: * Embed libneon and host into the SyncEvolution packages, so that DAV support can finally be enabled. * Various fixes and enhancements to KCalExtended backend. - Support synchronizing tasks and notes. - In --print-databases, list UIDs instead of file name (all listed calendars have the same file name anyway). Allow selecting database by UID in addition to name. - Only load one copy of the whole calendar into RAM when starting the sync. It shouldn't be necessary to load two. - Fixed failures when refreshing from remote peer and the local database wasn't empty, and other bugs. * Patches and updates from Fremantle merged into Harmattan tree. The tasks and notes support is untested. Please report on how it works. I also tried two other ways to improve the KCalExtended backend: 1. Convert it to TrackingSyncSource, for better reliability. This proved infeasible because insertItem() needs to return a new revision, but the new revision is not generated before calling save(), which is only done in endSync(). And, of course, calling save() for every single item is abysmally slow (and I couldn't even get it to work properly). However, it might still be possible to rewrite the backend to be TrackingSyncSource-*like*, with the difference of loading the new revisions in endSync() instead of in insertItem(), which would not be as slow. But probably still slower than the current approach. 2. Use partial loading of the calendar, to reduce memory requirements. It turns out that the bug that caused this feature to be disabled, bugs.meego.com/6061, is not actually fixed. It's fixed if a save() is done between step 3 and 4 in Patrick's recipe, but it still fails if there's no save(). And again, doing a save() in every single deleteItem or insertItem is not desirable. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
