Evolution Data Server
Recently, MeeGo switched to GNOME’s Evolution Data Server for storage of contacts, calendar, etc, though not for the API, which remains QtContacts, via the qtcontacts-eds backend. To help with that, Openismus has been making e-d-s performance improvements for Intel. For instance, to avoid unnecessary transfer of data across D-Bus.
Tristan Van Berkom is doing the work, excellently as always, using upstream bugzilla, the mailing list, and upstream’s git.gnome.org. It’s gradually all going into the master branch. There are some special patches only for Meego’s branch, because it is based on the gnome-2-32 branch, whose API is partly deprecated in master. But we are taking the time to make equivalent changes in master’s new API.
We had worked on Maemo 5 (Fremantle)’s e-d-s fork, which used similar techniques to achieve the N900’s performance. But the developers weren’t given time to submit changes properly upstream. Also, some improvements were spread across other modules, some proprietary, though with hindsight the developers generally feel that many changes would have been better in evolution-data-server itself. It’s great that Intel are pushing for it to be done properly now.
Meanwhile we are also working on the qtcontacts-tracker backend alternative, which we like too.
SyncEvolution
At the same time, MeeGo switched to SyncEvolution for synchronization of contacts, calendar, etc with online services (via SyncML and other protocols) and with bluetooth phones. We are helping Intel with that too.
Chris Kühl has done some code cleanup which should hit the master branch soon and he is now letting SyncEvolution identify some phones via their Bluetooth Device ID profiles, where they exist. That could make configuration easier because the user won’t need to tell SyncEvolution what the phone can do or what quirks it has. Again, this is all via bugzilla, the mailing list, and gitorious, targeting the master branch.
Lastly, I’ve done some cleanup of the syncevolution.org website, simplifying its structure, and updating some text so it makes sense as a whole. I am still not fond of Drupal. David King wrote and updated the website’s documentation about the syncevolution command-line and GUI.
This is awesome and great to see more attention on an area that can certainly needs it on linux. PC phone sync is something that is lacking.
As the package maintainer in Fedora one thing I would really like to see is the splitting out of the various libraries such as libsynthesis that are bundled in a release of syncevolution, at least for the source code releases. If there’s also a separate combined tarfile that’s cool but separate releases (similar to the various evolution components) would be useful for distros.
Peter, the syncevolution build can use an external libsynthesis already, I think. As far as I can tell, there are no real libsynthesis releases, but I don’t know the maintainers yet. It’s already packaged separately on Ubuntu but seems to be older than what’s needed by syncevolution.
yes, in theory it can, in practice it doesn’t work. It would be nice to see releases together and the syncevolution source tar file not bundling any of the libraries at all like is pretty standard on most open source projects. And there are other bundled libraries too.
I have filed an enhancement request to provide separate libsynthesis .tar.gz archives: https://bugs.meego.com/show_bug.cgi?id=22539
I’ll see what I can do about that in a 1.2.1 update. Synthesis themselves do not release .tar.gz archives for Linux, this is happening as part of releasing SyncEvolution by me.
What other bundled libraries do you mean? The gdbus utility code? That is not meant to be shared between apps and thus packaging it separately from SyncEvolution does not make sense.
Openismus is going to look into using the new glib dbus APIs in SyncEvolution. This issue thus might become mute for future releases (SyncEvolution 1.3?) on distros with recent enough glib.