Re: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
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.