2:59 a.m.
On Sa, 2011-12-31 at 09:44 +0100, justus-bulk(a)piater.name wrote:
I then installed
http://people.debian.org/~ovek/harmattan/syncevolution_1.2.1-1_armel.deb
on the N9, and set up syncevolution with syncevo-http-server on the
laptop. This produced first success: I can sync contacts and multiple
caledars over an IP connection. However:
- There appears to be no way to sync memos and todos using this setup.
Both are apparently stored inside /home/user/.calendar/db on the N9,
along with the calendar data, but from inspecting the source code of
this Harmattan syncevolution build it appears that these cannot
currently be sync'ed because this has simply not yet been implemented.
True. If a developer with access to Harmattan is sufficiently motivated,
then implementing that support won't be hard.
- Sync is extremely slow. My 1000+ contacts take more than 10
minutes
to sync, even if there are no changes on either side. (On my Palm
this takes about 1 second, even if there are records to be sync'ed.)
The N9 syncevolution client fully charges the CPU for much of this
time.
I wrote the original QtContacts backend in SyncEvolution. Nokia didn't
wanted to use SyncEvolution, therefore I have never had access to a N9
and have not done any benchmarks on it.
10 minutes is indeed very slow. Are you interested in investigating this
further?
First, does the SyncEvolution binary or the synccompare perl script
consume the CPU time? You said that it is be binary, but I want to be
sure. Invoking the perl script is controlled by printChanges.
Second, is SyncEvolution creating automatic backups as part of each sync
session? Have a look at ~/.cache/syncevolution/<session> and look for
addressbook.before/after. This feature can be disabled by setting both
dumpData=0 and printChanges=0.
Second, if merely exporting the data is slow, can you measure that
separately? Try
time syncevolution --export /dev/null "your config name" addressbook
- I had trouble getting all of my data onto the N9 because of
timeouts
and other issues. I was completely unable to transfer my 13 years
worth of appointments ("D-Bus peer has disconnected" after many
minutes and transferring 212/5955 appointments), and had to resort to
moving the entire past into an unsync'ed calendar on the laptop.
That hints towards timeouts somewhere, but without detailed logs from
both sides it is hard to tell where.
Support for partial calendar sync (by time range, for example) has been
on the backlog for a long time, but never made it into the actual
feature planning. Again, a sufficiently developer should be able to add
such a feature. I'd be happy to point in the right direction. Would be
harder than the todo/memo support, though.
Thus, I am interested in trying out the N9's built-in sync
facilities
instead of the custom Harmattan syncevolution client,
I understand you frustration, but keep in mind that at least the
SyncEvolution still has an active maintainer (Ove) and an active
upstream project (syncevolution.org). The built-in sync is pretty much a
dead end. It's calendar sync is considerably limited (only does
vCalendar, for example).
but I have found
no way to do this:
- Is there a way to use syncevolution on the laptop to initiate a sync
with the N9 using OBEX over USB?
No, not supported by SyncEvolution at this point. Only OBEX/Bluetooth is
implemented.
- I have not found a way initiate on the N9 a sync with the laptop
(short of installing Funambol or something, which I'd prefer to
avoid).
Correct. A phone is typically not meant to be the initiator of a local
sync.
- The latter should work via bluetooth, but I have not found a way
to
get my laptop to advertise OPP, so the N9 does not offer the (paired)
laptop as a sync peer. Any hints?
The other way (laptop -> N9) is what Frederik got to work with one Linux
distro - see his reply for details.
--
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.