On So, 2010-02-14 at 00:07 +0000, Pietro Battiston wrote: > It seems to be working great, just a couple of observations (which, as > far as I can tell, pertain to syncevolution in general):
Correct. > - the first thing I tried to do was to get all my stuff from > scheduleworld to a Debian where I had never used Evolution: more > precisely, I _had_ started it once and registered an email address, but > I had never used the addressbook. The sync failed giving a "500" error. > All was needed to make it work was to switch to the addressbook view of > Evolution (I didn't even have to create some contact, just visualizing > it was enough) - then, syncs started working. This happened in a Debian > sid: if you are unable to reproduce, I can try to get more informations. I can reproduce it. In fact, it is a known issue and even listed as such on syncevolution.org ;-) I understand that a better solution inside the program would be nice, but I'm not sure what to do about it. The system address book is listed by libebook, but isn't usable unless Evolution does something to create it. > - when I sync (apart from the first time), before starting any network > communication, a perl process spawned by syncevolution starts consuming > all the CPU (a Turion at 2.10 Ghz) for something less than a minute (I > have ~3000 contacts). If it's necessary and known, no particular > problem: though maybe perl is not the perfect language for such > CPU-intensive task, you guys certainly know better than me... The synccompare script is very regex-heavy, so for that Perl was a better language and more widely available than the corresponding C++ libs. But yes, a rewrite in C++ would be nice, and has been on the list for a while: http://bugzilla.moblin.org/show_bug.cgi?id=2432 On the other hand, with some changes that I have pending for SyncEvolution 1.0, synccompare will be a lot faster for most cases because common item files will not be included in the slow diff/normalization part. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
