7:17 a.m.
On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote:
On Wed, 2011-09-07 at 08:23 +0200, Patrick Ohly wrote:
> **Warning:** in local sync, the sync config side acts as
> server. Therefore the ``from-server`` variants
> (``one-way-from-server``, ``refresh-from-server``) transfer data
> from the sync config into the target config. The ``from-client``
> variants transfer in the other direction, even if the target config
> happens to access data on a remote server.
>
> Hmm, it is not obvious that this also applies to syncing with devices
> via Bluetooth.
>
> This issue came up before, but there was no conclusion about the naming.
> Should it be "refresh/one-way-from-peer" and
> "refresh-the-peer/one-way-to-peer"? "refresh/one-way-from-local"
and
> "refresh/one-way-to-local"?
I don't totally know what would've been obvious here - I don't think I
have a good enough handle on things to give good input.
Let me phrase the question differently: if the options for "--sync" aka
"--source-property sync" had been named as follows, would that have
avoided the problem?
$ syncevolution --sync ?
--sync
Requests a certain synchronization mode when initiating a sync:
two-way = only send/receive changes since last sync
slow = exchange all items
refresh-from-remote = discard all local items and replace with
the items on the peer
refresh-from-local = discard all items on the peer and replace
with the local items
one-way-from-remote = transmit changes from peer
one-way-from-local = transmit local changes
disabled (or none) = synchronization disabled
refresh/one-way-from-server/client are also supported. Their use is
discouraged because the direction of the data transfer depends
on the role of the local side (can be server or client), which is
not always obvious.
When accepting a sync session in a SyncML server (HTTP server), only
sources with sync != disabled are made available to the client,
which chooses the final sync mode based on its own configuration.
When accepting a sync session in a SyncML client (local sync with
the server contacting SyncEvolution on a device), the sync mode
specified in the client is typically overridden by the server.
And even if that doc snippet doesn't clearly refer to bluetooth,
I still
didn't read it...
I know, this warning isn't the right way of solving the problem. From
which documentation did you learn about the available sync modes?
> > After syncing with the laptop, going back to the desktop
works, but
> > forces a slow sync. Repeating this seems to indicate that it always
> > needs to slow sync calendar+todo, even if there are no changes. Is this
> > expected behavior?
>
> No. Does this only happen for calendar+todo, but not for addressbook?
Hmm - I could reproduce this 100% last night, but not at all this
afternoon. Syncs are normal when there's nothing to update, but I've
run into another weird issue - data doesn't always sync through both
"hops"
Here's a case where I edit a contact on desktop, sync desktop<->phone,
Anchors from that sync:
[2011-09-07 17:33:55.029] Saved Last Remote Client Anchor='845', received
<last> Remote Client Anchor='845' (must match for normal sync)
[2011-09-07 17:33:55.029] Received <next> Remote Client Anchor='845' (to be
compared with <last> in NEXT session)
[2011-09-07 17:33:55.029] (Saved) Last Local Server Anchor='20110907T212942Z',
(generated) Next Local Server Anchor='20110907T213355Z' (sent to client as
<last>/<next> in <alert>)
sync laptop<->phone. The edited Contact doesn't get sent
to the laptop
from the phone.
[2011-09-07 17:35:20.989] Saved Last Remote Client Anchor='847', received
<last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:20.989] Received <next> Remote Client Anchor='847' (to be
compared with <last> in NEXT session)
[2011-09-07 17:35:20.989] (Saved) Last Local Server Anchor='20110907T213407Z',
(generated) Next Local Server Anchor='20110907T213520Z' (sent to client as
<last>/<next> in <alert>)
Why the phone doesn't send the contact is unknown. That's decided by the
phone itself.
Then, I go back an sync on the desktop and it does a slow sync with
no
changes to either side.
[2011-09-07 17:35:35.325] Saved Last Remote Client Anchor='845', received
<last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:35.325] Received <next> Remote Client Anchor='847' (to be
compared with <last> in NEXT session)
[2011-09-07 17:35:35.325] (Saved) Last Local Server Anchor='20110907T213355Z',
(generated) Next Local Server Anchor='20110907T213535Z' (sent to client as
<last>/<next> in <alert>)
[2011-09-07 17:35:35.325] (Saved) fResumeAlertCode = 0 (valid for >DS 1.2 only)
+–[2011-09-07 17:35:35.325] 'DSStateChange' - Datastore changes state,
datastore=addressbook, oldstate=admin_ready, newstate=server_alerted [--][++] [->end]
[->enclosing]
–[2011-09-07 17:35:35.325] End of 'DSStateChange' [->top] [->enclosing]
[2011-09-07 17:35:35.325] Alerted (code=200) for two-way Normal Sync
[2011-09-07 17:35:35.325] Switched to SlowSync because of Anchor mismatch or server-side
user option
[2011-09-07 17:35:35.325] Created command 'Alert' (outgoing)
[2011-09-07 17:35:35.325] ALERTED from client for slow Sync
Note that the phone sent 845 as its next anchor in the first sync. Now
it sends 847 instead, which is wrong.
Further subsequent syncs, even slow sync, doesn't ever sync this
update
to the laptop.
Just for the sake of completeness:
[2011-09-07 17:41:19.575] Saved Last Remote Client Anchor='847', received
<last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:41:19.575] Received <next> Remote Client Anchor='847' (to be
compared with <last> in NEXT session)
[2011-09-07 17:41:19.575] (Saved) Last Local Server Anchor='20110907T213520Z',
(generated) Next Local Server Anchor='20110907T214119Z' (sent to client as
<last>/<next> in <alert>)
To me this looks like the phone doesn't properly distinguish among the
peers it syncs with. That pretty much breaks the sync topology where the
phone is the hub through which all data must pass.
Perhaps you can make your desktop that hub instead by synchronizing both
the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
make the laptop the hub, synchronizing against the phone via Bluetooth
and against the desktop via HTTP
(http://syncevolution.org/wiki/http-server-howto).
--
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.
4:30 p.m.
New subject: [SyncEvolution] Multi-point sync
On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote:
On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote:
Let me phrase the question differently: if the options for "--sync" aka
"--source-property sync" had been named as follows, would that have
avoided the problem?
$ syncevolution --sync ?
--sync
Requests a certain synchronization mode when initiating a sync:
two-way = only send/receive changes since last sync
slow = exchange all items
refresh-from-remote = discard all local items and replace with
the items on the peer
refresh-from-local = discard all items on the peer and replace
with the local items
one-way-from-remote = transmit changes from peer
one-way-from-local = transmit local changes
disabled (or none) = synchronization disabled
refresh/one-way-from-server/client are also supported. Their use is
discouraged because the direction of the data transfer depends
on the role of the local side (can be server or client), which is
not always obvious.
When accepting a sync session in a SyncML server (HTTP server), only
sources with sync != disabled are made available to the client,
which chooses the final sync mode based on its own configuration.
When accepting a sync session in a SyncML client (local sync with
the server contacting SyncEvolution on a device), the sync mode
specified in the client is typically overridden by the server.
Yes, this explains the situation quite clearly - I think this is a clear
improvement.
> And even if that doc snippet doesn't clearly refer to
bluetooth, I still
> didn't read it...
I know, this warning isn't the right way of solving the problem. From
which documentation did you learn about the available sync modes?
I looked at the manpage.
To me this looks like the phone doesn't properly distinguish
among the
peers it syncs with. That pretty much breaks the sync topology where the
phone is the hub through which all data must pass.
Aha - that's very helpful. This makes some sense, it's a Symbian S40
phone. Seems likely that they'd make some (bad) simplifying
assumptions.
Perhaps you can make your desktop that hub instead by synchronizing
both
the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
make the laptop the hub, synchronizing against the phone via Bluetooth
and against the desktop via HTTP
(http://syncevolution.org/wiki/http-server-howto).
Yea, something like this should help me a lot. I can keep the two
computers in sync so the phone doesn't need to distinguish between them.
I'll try this next time I get the chance. Thanks very much Patrick -
this was really helpful.
Ross
--
Ross Vandegrift <ross(a)kallisti.us>
5:52 p.m.
New subject: [SyncEvolution] Multi-point sync
On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote:
Perhaps you can make your desktop that hub instead by synchronizing
both
the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
make the laptop the hub, synchronizing against the phone via Bluetooth
and against the desktop via HTTP
(http://syncevolution.org/wiki/http-server-howto).
I've tried to work through these instructions a few times to get my two
syncevolution instances talking, but I'm not quite there. I have
figured out how to get the syncevolution server and client setup using
the appropriate templates, and I have figured out the various
authentication issues.
The tutorial refers to "${datapath}" without indicating where this is
supposed to point. Do I need to point the syncevolution server to the
files where evolution stores the particular type of data that I am
trying to sync? If so, how can I figure this out?
Things look like they are working - syncevolution's output looks like a
working sync. But (I suspect because of the above), none of these make
it into the client's Evolution instance.
Thanks for any hints,
Ross
--
Ross Vandegrift <ross(a)kallisti.us>
6:58 a.m.
New subject: [SyncEvolution] Multi-point sync
On Sun, Sep 25, 2011 at 13:52:55 -0400, Ross Vandegrift wrote:
On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote:
> Perhaps you can make your desktop that hub instead by synchronizing both
> the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
> make the laptop the hub, synchronizing against the phone via Bluetooth
> and against the desktop via HTTP
> (http://syncevolution.org/wiki/http-server-howto).
I've tried to work through these instructions a few times to get my two
syncevolution instances talking, but I'm not quite there. I have
figured out how to get the syncevolution server and client setup using
the appropriate templates, and I have figured out the various
authentication issues.
The tutorial refers to "${datapath}" without indicating where this is
supposed to point. Do I need to point the syncevolution server to the
files where evolution stores the particular type of data that I am
trying to sync? If so, how can I figure this out?
If you use the file storage backend instead of evolution-data-server
(evolutionsource=file://...), the path refers to the place where
syncevolution stores its files for PIM data. As it is user specific
data, a good place would be in the users home directory, like
/home/<username>/.syncevolution-data.
Things look like they are working - syncevolution's output looks
like a
working sync. But (I suspect because of the above), none of these make
it into the client's Evolution instance.
This is correct if you use the file storage backend and not the
evolution-data-server storage backend.
The file storage backend is intended for a syncevolution server that
does not run evolution and evolution-data-server, like a headless
server somewhere in the internet.
Regards,
Tino
8:39 a.m.
New subject: [SyncEvolution] Multi-point sync
On Mon, 2011-09-26 at 08:58 +0200, tino.keitel+syncevolution(a)tikei.de
wrote:
On Sun, Sep 25, 2011 at 13:52:55 -0400, Ross Vandegrift wrote:
> On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote:
> > Perhaps you can make your desktop that hub instead by synchronizing both
> > the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
> > make the laptop the hub, synchronizing against the phone via Bluetooth
> > and against the desktop via HTTP
> > (http://syncevolution.org/wiki/http-server-howto).
>
> I've tried to work through these instructions a few times to get my two
> syncevolution instances talking, but I'm not quite there. I have
> figured out how to get the syncevolution server and client setup using
> the appropriate templates, and I have figured out the various
> authentication issues.
>
> The tutorial refers to "${datapath}" without indicating where this is
> supposed to point. Do I need to point the syncevolution server to the
> files where evolution stores the particular type of data that I am
> trying to sync? If so, how can I figure this out?
If you use the file storage backend instead of evolution-data-server
(evolutionsource=file://...), the path refers to the place where
syncevolution stores its files for PIM data. As it is user specific
data, a good place would be in the users home directory, like
/home/<username>/.syncevolution-data.
Correct. Thanks for answering while I was on vacation.
I've also updated the Wiki page to cover this aspect.
--
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:27 a.m.
New subject: [SyncEvolution] Multi-point sync
On Mon, 2011-09-26 at 08:58 +0200, tino.keitel+syncevolution(a)tikei.de
wrote:
> Things look like they are working - syncevolution's output
looks like a
> working sync. But (I suspect because of the above), none of these make
> it into the client's Evolution instance.
This is correct if you use the file storage backend and not the
evolution-data-server storage backend.
The file storage backend is intended for a syncevolution server that
does not run evolution and evolution-data-server, like a headless
server somewhere in the internet.
Aha - finally sat down tonight and went through this again. Finally got
the HTTP server sync working well. This is much easier than the wiki
HOWTO makes it look - the SyncEvolution template does most of the work.
Wrote up a quick walkthrough:
http://syncevolution.org/wiki/synchronizing-evolution-evolution-http-howto
Haven't gone back to see what happens if I sync my phone with both of
the evolution instances. Some other night.
Thanks for all the help!
Ross
--
Ross Vandegrift <ross(a)kallisti.us>
9:59 a.m.
New subject: [SyncEvolution] Multi-point sync
On Wed, 2011-10-05 at 21:27 -0400, Ross Vandegrift wrote:
On Mon, 2011-09-26 at 08:58 +0200,
tino.keitel+syncevolution(a)tikei.de
wrote:
> > Things look like they are working - syncevolution's output looks like a
> > working sync. But (I suspect because of the above), none of these make
> > it into the client's Evolution instance.
>
> This is correct if you use the file storage backend and not the
> evolution-data-server storage backend.
>
> The file storage backend is intended for a syncevolution server that
> does not run evolution and evolution-data-server, like a headless
> server somewhere in the internet.
Aha - finally sat down tonight and went through this again. Finally got
the HTTP server sync working well. This is much easier than the wiki
HOWTO makes it look - the SyncEvolution template does most of the work.
Wrote up a quick walkthrough:
http://syncevolution.org/wiki/synchronizing-evolution-evolution-http-howto
Thanks, that is useful. I've cross-linked the two HOWTO's with some
hints for readers so that they can follow the one more appropriate for
them.
--
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.
10:11 a.m.
New subject: [SyncEvolution] Multi-point sync
On Thu, 2011-09-08 at 12:30 -0400, Ross Vandegrift wrote:
On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote:
> On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote:
> Let me phrase the question differently: if the options for "--sync" aka
> "--source-property sync" had been named as follows, would that have
> avoided the problem?
>
> $ syncevolution --sync ?
> --sync
> Requests a certain synchronization mode when initiating a sync:
> two-way = only send/receive changes since last sync
> slow = exchange all items
> refresh-from-remote = discard all local items and replace with
> the items on the peer
> refresh-from-local = discard all items on the peer and replace
> with the local items
> one-way-from-remote = transmit changes from peer
> one-way-from-local = transmit local changes
> disabled (or none) = synchronization disabled
>
> refresh/one-way-from-server/client are also supported. Their use is
> discouraged because the direction of the data transfer depends
> on the role of the local side (can be server or client), which is
> not always obvious.
>
> When accepting a sync session in a SyncML server (HTTP server), only
> sources with sync != disabled are made available to the client,
> which chooses the final sync mode based on its own configuration.
> When accepting a sync session in a SyncML client (local sync with
> the server contacting SyncEvolution on a device), the sync mode
> specified in the client is typically overridden by the server.
Yes, this explains the situation quite clearly - I think this is a clear
improvement.
Created https://bugs.meego.com/show_bug.cgi?id=23537 to track the
proposal. It's too late for 1.2, so I made the warning about this
problem a bit more prominent in the 1.2 README.
--
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.
3964
days inactive
3993
days old
syncevolution@synevolution.org
7 comments
3 participants
participants (3)
-
Patrick Ohly -
Ross Vandegrift -
tino.keitel+syncevolution＠tikei.de