2:44 a.m.
Hi -
I am having trouble getting my N9 to sync with my Linux box, probably at
least partially due to my limited understanding of how the N9 is set up
internally.
I first tried syncml-ds-tool, which allows me to shuffle data back and
forth via USB/OBEX or Bluetooth/OBEX, but no real record-wise sync.
I then tried opensync over bluetooth, but am having persistent bluetooth
problems (I cannot browes files on the N9 over obexftp using any tool,
for example), so I gave up on this front for now. Any advice would be
appreciated.
I have not tried opensync over USB. Perhaps this would be a promising
route. Any advice would be appreciated.
I tried syncevolution over bluetooth, but persistently got transport
errors (presumably for the same reasons as the opensync troubles), and
gave up for now.
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.
- 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 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.
Thus, I am interested in trying out the N9's built-in sync facilities
instead of the custom Harmattan syncevolution client, 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?
- 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).
- 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?
Given this experience, I am puzzled by Fredrik's announcement of success:
On Tue, 2011-10-25 at 12:59 +0200, Frederik Elwert wrote:
I recently got a Nokia N9, and I am now experimenting with
SyncEvolution to get my Desktop and the N9 in sync.
It started fairly promising: I could add the N9 with the Nokia
template in sync-ui. In general, sync works quite fine. So the N9
seems to be capable enough by default to get this kind of things
right.
Perhaps I am missing something obvious? Any suggestions are welcome.
Justus
3:08 a.m.
Hi Justus,
Am Samstag, den 31.12.2011, 09:44 +0100 schrieb justus-bulk(a)piater.name:
I then tried opensync over bluetooth, but am having persistent
bluetooth
problems (I cannot browes files on the N9 over obexftp using any tool,
for example), so I gave up on this front for now. Any advice would be
appreciated.
[…]
I tried syncevolution over bluetooth, but persistently got transport
errors (presumably for the same reasons as the opensync troubles), and
gave up for now.
Which OS are you using on your laptop? There seem to be a couple of
bluetooth related bugs in recent linux distros, e.g. Ubuntu 11.10. There
seems to be a kernel bug, but also the GNOME bluetooth stack has issues.
I am not yet really sure which issue causes these problems for
SyncEvolution.
Given this experience, I am puzzled by Fredrik's announcement of
success:
On Tue, 2011-10-25 at 12:59 +0200, Frederik Elwert wrote:
> I recently got a Nokia N9, and I am now experimenting with
> SyncEvolution to get my Desktop and the N9 in sync.
>
> It started fairly promising: I could add the N9 with the Nokia
> template in sync-ui. In general, sync works quite fine. So the N9
> seems to be capable enough by default to get this kind of things
> right.
Perhaps I am missing something obvious? Any suggestions are welcome.
There might be a simple answer: I use my work machine for sync, which
still runs Ubuntu 10.04. Bluetooth works there.
With SyncEvolution on the desktop, and using the built-in SyncML support
of the N9, I managed to sync successfully, and I am using this solution
on a regular basis. However, it has its flaws, as timezone information
being lost, etc. So there is still room for improvement.
Regards
Frederik
12:59 p.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.
3:35 p.m.
Dear Patrick,
Thank you for your exhaustive answer.
Patrick Ohly <patrick.ohly(a)intel.com> wrote on Thu, 05 Jan 2012 19:59:35
+0100:
> - 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.
This was my impression. Getting these sync'ed as well would really make
my day. I can probably do it myself, but I cannot currently consecrate
significant time to it, and I am a stranger to the sync/evolution code.
Perhaps this summer. Unless someone else picks up this thread in the
meantime, would you work with me through this?
10 minutes is indeed very slow. Are you interested in investigating
this
further?
Yes, I am!
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.
It is the syncevolution binary.
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.
Yes, they are both there, containing 1062 VCARDs each.
What are the risks and implications of disabling this feature? Nothing
more or less than loss of PIM data if a sync goes horribly wrong?
My evolution DBs on the laptop as well as the PIM DBs on the N9 are
backed up by my routine rsync backups. Can't Evolution be restored from
those backups if need be? Do I need to take the export route? If the
issue is merely one of avoiding races between backup reads and
simultaneous writes, then I can handle that.
Second, if merely exporting the data is slow, can you measure that
separately? Try
time syncevolution --export /dev/null "your config name" addressbook
/home/user $ time syncevolution --export /dev/null client-for-laptop addressbook
real 4m 17.97s
user 4m 4.85s
sys 0m 2.35s
So this is it! Export before + export after = almost the entire time of
the sync! This also presumably explains why the sync appears to sit
idle for minutes after displaying "[INFO] addressbook: normal sync done
successfully".
> - 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.
No big issue for me. But now that I've learned how to set the timeouts
(for the addressbook sync), I may give this another shot one day. I'll
report here if I learn something interesting along the way.
> 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,
I indeed moved quite close to the limits of my patience, and I feared
that I did not quite succeed in hiding it :-/ But let it be heard that I
am extremely grateful for your work and that of all those other FOSS
developers that allow me to live in near-complete software freedom. I
wish my professional constraints allowed me to give back more to the
community.
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).
Good points. I'll stick with SyncEvolution for now.
Best,
Justus
1:13 a.m.
On Do, 2012-01-05 at 22:35 +0100, Justus-bulk(a)Piater.name wrote:
Patrick Ohly <patrick.ohly(a)intel.com> wrote on Thu, 05 Jan 2012
19:59:35
+0100:
>> - 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.
This was my impression. Getting these sync'ed as well would really make
my day. I can probably do it myself, but I cannot currently consecrate
significant time to it, and I am a stranger to the sync/evolution code.
Perhaps this summer. Unless someone else picks up this thread in the
meantime, would you work with me through this?
Of course.
> 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.
Yes, they are both there, containing 1062 VCARDs each.
What are the risks and implications of disabling this feature? Nothing
more or less than loss of PIM data if a sync goes horribly wrong?
Yes, exactly that.
printChanges is useful for detecting undesired changes and/or to keep
informed about updates. When not watching the output it can be safely
turned off. printChanges uses the same data dumps as dumpData.
dumpData controls whether the automatic backups are still done when not
needed for printChanges.
My evolution DBs on the laptop as well as the PIM DBs on the N9 are
backed up by my routine rsync backups. Can't Evolution be restored from
those backups if need be? Do I need to take the export route? If the
issue is merely one of avoiding races between backup reads and
simultaneous writes, then I can handle that.
If you have other backups, then you don't need SyncEvolution's builtin
backup mechanism. It's there and enabled by default because many people
don't have that, or don't backup frequently enough.
> Second, if merely exporting the data is slow, can you measure
that
> separately? Try
> time syncevolution --export /dev/null "your config name" addressbook
/home/user $ time syncevolution --export /dev/null client-for-laptop addressbook
real 4m 17.97s
user 4m 4.85s
sys 0m 2.35s
So this is it! Export before + export after = almost the entire time of
the sync! This also presumably explains why the sync appears to sit
idle for minutes after displaying "[INFO] addressbook: normal sync done
successfully".
I should add an INFO message for the data dumps. You are not the first
to wonder what SyncEvolution is doing.
It should also be possible to optimize the dumping of the entire
database. Right now, detecting changes and data dumps take different
code paths (Intentionally! A bug in change detection should not break
the backups) and happen to read one item at a time where batch
operations would be more efficient.
>> 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,
I indeed moved quite close to the limits of my patience, and I feared
that I did not quite succeed in hiding it :-/
No worries, I found your email quite helpful.
--
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.
11:28 a.m.
New subject: [SyncEvolution] Nokia N9 Progress (was Re: Nokia N9 Woes)
Hi Patrick,
I do not seem to be able to turn off the exhaustive dumps. I did:
/home/user $ syncevolution --configure printChanges=false client-for-laptop
/home/user $ syncevolution --configure dumpData=false client-for-laptop
which caused
printChanges = 0
dumpData = 0
to appear in
/home/user/.config/syncevolution/default/peers/client-for-laptop/config.ini.
However, the dumps still appear. Here is a related excerpt from the N9
client log (followed by some scary stuff that is probably not directly
related but may contribute to the slow dump):
[2012-01-06 18:03:18.778] addressbook: starting normal sync, two-way
[2012-01-06 18:03:18.780] =================> Finished processing incoming message #1
(final), request=0
[2012-01-06 18:03:18.781] MessageEnded finishes : new outgoing state='sync', new
incoming state='sync', NeedToAnswer
[2012-01-06 18:03:18.782] Local Datastore 'addressbook': State=sync_mode_stable,
normal sync, two-way
[2012-01-06 18:03:18.783] Local Datastore 'addressbook' - Types: tx to remote:
'vCard21': text/x-vcard (2.1), rx from remote: 'vCard30': text/vcard
(3.0)
–
[2012-01-06 18:03:18.784] 'DSStateChange' - Datastore changes state,
datastore=addressbook, oldstate=sync_mode_stable, newstate=data_access_started [--][++]
[->end] [->enclosing]
[2012-01-06 18:03:18.785] TStdLogicDS::startDataAccessForClient
[2012-01-06 18:03:18.785] Executing Script 'datastoreinitscript'
–
[2012-01-06 18:03:18.786] 'ReadSyncSet' - Reading Sync Set from Database,
datastore=addressbook [--][++] [->end] [->enclosing]
[2012-01-06 18:03:18.787] 'addressbook' dev='anydevice'
usr='singleuser' err=0
[2012-01-06 18:03:18.788] FilterSupport staticfilter:
dynamicfilter:
invisiblefilter:
[2012-01-06 18:03:18.789] Executing Script 'initscript'
[2012-01-06 18:03:18.790] Now reading local sync set: report changes since
reference1 at 2012-01-06 16:43:34.517, and since reference2 at 2012-01-06 16:43:34.517
[2012-01-06 18:03:18.807] creating
/home/user/.cache/syncevolution/client_+for_+laptop-2012-01-06-18-03/addressbook.before
[2012-01-06 18:08:00.843] libqtcontacts-tracker: engine.cpp:1873:
=============================================================================
WARNING /!\ - NEVER EVER CALL THIS FUNCTION FROM PRODUCTION CODE!!!
=============================================================================
QContactAbstractRequest::waitForFinished(), respectively
QContactManagerEngine::waitForRequestFinished() must spin your
application's event loop. Doing so will cause HAVOC AND PAIN for
any non-trivial program.
So please refactor your asynchronious code, or use the synchronious
API if blocking your application is acceptable.
WE MEAN IT!!!
Offending application is /usr/bin/syncevolution [9256].
=============================================================================
[repeated many times]
...
[2012-01-06 18:08:00.926]
/home/user/.cache/syncevolution/client_+for_+laptop-2012-01-06-18-03/addressbook.before
created
[2012-01-06 18:08:00.933] using full item scan to detect changes
[2012-01-06 18:08:01.519] StartDataRead last='1' resume='1' res=0
[2012-01-06 18:08:01.520] ReadNextItemAsKey aStatus=2 aID=(138216,(null)) res=0
[2012-01-06 18:08:01.520] ReadNextItemAsKey aStatus=2 aID=(138222,(null)) res=0
[repeated many times]
Another question: Instead of sync'ing over USB with syncevo-http-server
on the laptop, can I sync over Bluetooth? I have not found an obvious
way to do this:
- Trying to configure syncevolution as an OBEX server results in
"[ERROR] unsupported transport type is specified in the
configuration".
- I found some vague pointers towards hooking up syncevolution with
obexd (the one commonly packaged as obexd-server, I gather) but it
conflicts with bluedevil (I use KDE) and other packages.
And a final, unrelated question: running KDE, it would be more natural
for me to use KOrganizer instead of Evolution. The logs say "Loading
backend library syncakonadi.so." I have not found conclusive
information about this backend. Is this a production-ready backend that
would allow me to sync with KOrganizer?
Many thanks,
Justus
11:44 a.m.
New subject: [SyncEvolution] Nokia N9 Progress (was Re: Nokia N9 Woes)
On Fr, 2012-01-06 at 18:28 +0100, Justus-bulk(a)Piater.name wrote:
I do not seem to be able to turn off the exhaustive dumps. I did:
/home/user $ syncevolution --configure printChanges=false client-for-laptop
/home/user $ syncevolution --configure dumpData=false client-for-laptop
which caused
printChanges = 0
dumpData = 0
to appear in
/home/user/.config/syncevolution/default/peers/client-for-laptop/config.ini.
Looks right.
However, the dumps still appear.
I need to check this. I'm in the middle of an extensive code rewrite, so
it might take until Monday or Tuesday.
Another question: Instead of sync'ing over USB with
syncevo-http-server
on the laptop, can I sync over Bluetooth? I have not found an obvious
way to do this:
- Trying to configure syncevolution as an OBEX server results in
"[ERROR] unsupported transport type is specified in the
configuration".
SyncEvolution itself can only be an OBEX client/SyncML server (yes, the
roles are reversed depending on the level in the stack). That's
typically the laptop/desktop side, which initiates a connection to a
mobile device (thus acts as OBEX client).
This is what obex+bt in the syncURL configures. It uses libopenobex, no
need for obexd.
- I found some vague pointers towards hooking up syncevolution with
obexd (the one commonly packaged as obexd-server, I gather) but it
conflicts with bluedevil (I use KDE) and other packages.
obexd needs to run on the N9. It must be invoked with a --syncevolution
option (or something like it, I don't remember the details). Then it'll
start syncevo-dbus-server via D-Bus to do actual syncs whenever someone
connects to obexd and asks for a SyncML session.
The syncevo-http-server uses the same D-Bus interface, so the actual
SyncEvolution code is well-tested, just not in combination with obexd.
It was meant to go into handheld devices, but as it happened,
SyncEvolution never actually was used for such devices. Nokia preferred
to stay with their own solution.
And a final, unrelated question: running KDE, it would be more
natural
for me to use KOrganizer instead of Evolution. The logs say "Loading
backend library syncakonadi.so." I have not found conclusive
information about this backend. Is this a production-ready backend that
would allow me to sync with KOrganizer?
I wouldn't call it production ready, although it has been around for a
while. The main problem is that I never got around to put it into
syncevolution.org binaries and the nightly testing. Partly this is
general lack of time, partly fear that if I enable it, I'll end up with
bugs that I cannot deal with unless some KDE developers are ready to
help.
It's still on the agenda for SyncEvolution 1.3.
--
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.
11:39 a.m.
New subject: [SyncEvolution] Nokia N9 Progress (was Re: Nokia N9 Woes)
On Fr, 2012-01-06 at 18:44 +0100, Patrick Ohly wrote:
On Fr, 2012-01-06 at 18:28 +0100, Justus-bulk(a)Piater.name wrote:
> I do not seem to be able to turn off the exhaustive dumps. I did:
>
> /home/user $ syncevolution --configure printChanges=false client-for-laptop
> /home/user $ syncevolution --configure dumpData=false client-for-laptop
>
> which caused
>
> printChanges = 0
> dumpData = 0
>
> to appear in
> /home/user/.config/syncevolution/default/peers/client-for-laptop/config.ini.
Looks right.
> However, the dumps still appear.
I need to check this. I'm in the middle of an extensive code rewrite, so
it might take until Monday or Tuesday.
I can reproduce it:
https://bugs.meego.com/show_bug.cgi?id=24619
A patch is also available. Disabling data dumps and controlling the
change printing basically didn't work at all as intended. No idea why I
didn't notice when testing the patch - probably I didn't test. How
embarrassing.
--
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.
2:25 a.m.
On Fr, 2012-01-06 at 08:13 +0100, Patrick Ohly wrote:
> > Second, if merely exporting the data is slow, can you
measure that
> > separately? Try
> > time syncevolution --export /dev/null "your config name"
addressbook
>
> /home/user $ time syncevolution --export /dev/null client-for-laptop
addressbook
> real 4m 17.97s
> user 4m 4.85s
> sys 0m 2.35s
>
> So this is it! Export before + export after = almost the entire time
of
> the sync! This also presumably explains why the sync appears to sit
> idle for minutes after displaying "[INFO] addressbook: normal sync
done
> successfully".
I should add an INFO message for the data dumps. You are not the first
to wonder what SyncEvolution is doing.
Are the following INFO messages informative enough?
[INFO] eds_contact: starting normal sync, two-way (peer is server)
[INFO] creating complete data backup before sync (enabled with dumpData and needed
for printChanges)
Local data changes to be applied during synchronization:
*** eds_contact ***
no changes
[INFO] eds_contact: started
[INFO] eds_contact: normal sync done successfully
[INFO] creating complete data backup after sync (enabled with dumpData and needed
for printChanges)
Synchronization successful.
This is the default case with dumpData=1 printChanges=1. The explanation
in brackets changes depending on these settings.
Only dumpData set:
[INFO] creating complete data backup before sync (because it was enabled with
dumpData)
Only printChanges set:
[INFO] creating complete data backup before sync (needed for printChanges)
It's not exactly a fix for https://bugs.meego.com/show_bug.cgi?id=24619
but as it is minor, I'll add that together with the fix to a 1.2.2
update (if that ever happens, not sure yet).
--
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.
1:45 a.m.
Den 05. jan. 2012 22:35, skrev Justus-bulk(a)Piater.name:
>> - 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.
This was my impression. Getting these sync'ed as well would really make
my day. I can probably do it myself, but I cannot currently consecrate
significant time to it, and I am a stranger to the sync/evolution code.
Perhaps this summer. Unless someone else picks up this thread in the
meantime, would you work with me through this?
It's something I could look into at some point, I suppose. But right
now, the little time I have for working on SyncEvolution is spent on
creating a new frontend GUI for Harmattan. Still a fair bit of work left
on that...
3306
days inactive
3316
days old
syncevolution@synevolution.org
9 comments
5 participants
participants (5)
-
Frederik Elwert -
justus-bulk＠piater.name -
Justus-bulk＠Piater.name
-
Ove Kåven -
Patrick Ohly