headers
Patrick Ohly | 11 Nov 2010 15:52
Picon
Favicon
Gravatar

slow-sync matching

Hello!

I have a question about matching items. Here's my situation:
      * Client and server both have the same iCalendar 2.0 VEVENT (UID
        is identical).
      * SUMMARY is changed on server, one line is added to description.
      * SUMMARY is changed on client.
      * Slow sync.

I had changed the "calendar" field list so that all fields have
compare="never", except for UID and ORIGSTART, which have
compare="always". The rationale is that if it is known that both sides
support UID, that alone should be used to find matches.

What I expect in this case is that:
     1. Synthesis engine finds the match.
     2. The more recently modified SUMMARY from the client is preserved
        (DMODIFIED = LAST-MODIFIED is marked as age="yes").
     3. The additional line of the description is preserved (DESCRIPTION
        has merge="lines").

What happens instead is that the engine finds the match, but then skips
merging the items and updating them on server and client, leaving them
unsynchronized. Is that the desired behavior? Do I have to configure the
engine differently?

From the log file:
# [2010-11-11 15:40:44.964] Testing filter '' against item:
# [2010-11-11 15:40:44.964] Filter test result is TRUE
# [2010-11-11 15:40:44.964] comparing (this) local item
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ohly | 15 Nov 2010 14:43
Picon
Favicon
Gravatar

Re: slow-sync matching

On Do, 2010-11-11 at 14:52 +0000, Patrick Ohly wrote:
> Hello!
> 
> I have a question about matching items. Here's my situation:
>       * Client and server both have the same iCalendar 2.0 VEVENT (UID
>         is identical).
>       * SUMMARY is changed on server, one line is added to description.
>       * SUMMARY is changed on client.
>       * Slow sync.
> 
> I had changed the "calendar" field list so that all fields have
> compare="never", except for UID and ORIGSTART, which have
> compare="always". The rationale is that if it is known that both sides
> support UID, that alone should be used to find matches.
> 
> What I expect in this case is that:
>      1. Synthesis engine finds the match.
>      2. The more recently modified SUMMARY from the client is preserved
>         (DMODIFIED = LAST-MODIFIED is marked as age="yes").
>      3. The additional line of the description is preserved (DESCRIPTION
>         has merge="lines").
> 
> What happens instead is that the engine finds the match, but then skips
> merging the items and updating them on server and client, leaving them
> unsynchronized. Is that the desired behavior? Do I have to configure the
> engine differently?

Yes. Lukas told me that there are configuration options, and then I also
found them in the documentation:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Patrick Ohly | 15 Nov 2010 17:50
Picon
Favicon
Gravatar

Re: slow-sync matching

On Mo, 2010-11-15 at 13:43 +0000, Patrick Ohly wrote:
> On Do, 2010-11-11 at 14:52 +0000, Patrick Ohly wrote:
> > Hello!
> > 
> > I have a question about matching items. Here's my situation:
> >       * Client and server both have the same iCalendar 2.0 VEVENT (UID
> >         is identical).
> >       * SUMMARY is changed on server, one line is added to description.
> >       * SUMMARY is changed on client.
> >       * Slow sync.
> > 
> > I had changed the "calendar" field list so that all fields have
> > compare="never", except for UID and ORIGSTART, which have
> > compare="always". The rationale is that if it is known that both sides
> > support UID, that alone should be used to find matches.
> > 
> > What I expect in this case is that:
> >      1. Synthesis engine finds the match.
> >      2. The more recently modified SUMMARY from the client is preserved
> >         (DMODIFIED = LAST-MODIFIED is marked as age="yes").
> >      3. The additional line of the description is preserved (DESCRIPTION
> >         has merge="lines").
> > 
> > What happens instead is that the engine finds the match, but then skips
> > merging the items and updating them on server and client, leaving them
> > unsynchronized. Is that the desired behavior? Do I have to configure the
> > engine differently?
> 
> Yes. Lukas told me that there are configuration options, and then I also
> found them in the documentation:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrick Ohly | 16 Nov 2010 10:07
Picon
Favicon
Gravatar

Re: slow-sync matching

On Mo, 2010-11-15 at 16:50 +0000, Patrick Ohly wrote:
> Now that I had that sorted out, I was running into another configuration
> issue: <slowsyncstrategy>duplicate</slowsyncstrategy> is set in the
> syncserv_sample_config.xml and SyncEvolution copied that. Therefore the
> engine ended up trying to duplicate events despite a UID match. This is
> not possible in the backend, which will always overwrite the existing
> event. So what I need in this case is "newer-wins" with "server-wins" or
> "client-wins" as fallback instead of "duplicate" - such a setting does
> not exist, does it?

After some more thinking I came to the conclusion that the fallback is
not needed for my iCalendar 2.0 case: because UID/RECURRENCE-ID will
always find pairs (if they exist) and LAST-MODIFIED is always there,
there will always be a "newer" item, so the "duplicate" fallback will
never trigger.

> Finally, remember that I had intentionally created differences in the
> SUMMARY of my two events. My expectation was that this difference would
> be resolved during syncing.
[...]
> Note that I made another change for my iCalendar 2.0 case: all fields
> have compare="never", only UID/RECURRENCE-ID has compare="always". Could
> that have an effect on merging once pairs are found? After looking at
> the code it seems so. compareWith() returns that the items are identical
> enough, despite the change in SUMMARY.

Yes, that was it. I had the idea of introducing a new "compare" level
between "never" and "conflict" to mark fields which are relevant for the
user (and thus changes must be stored), without using them to find pairs
(which levels >= "conflict" would do).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andris Pavenis | 24 Nov 2010 15:07
Picon

libsynthesissdk.a built without -fPIC

  libsynthesissdk.a can be linked into external libsynthesis plugins, but
is built without -fPIC. It works OK for 32 bit Linux but not 64 bit Linux.

I'm getting error message:
/usr/bin/ld: 
/usr/lib64/libsynthesissdk.a(libsynthesissdk_la-SDK_support.o): 
relocation R_X86_64_32 against `a local symbol' can not be used when 
making a shared object; recompile with -fPIC
/usr/lib64/libsynthesissdk.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

I added following patch when building own RPM package 
(libsynthesis-3.4.0.16)

--- libsynthesis_3.4.0.16/src/Makefile.am.in.orig       2010-11-24 
15:52:52.000000000 +0200
+++ libsynthesis_3.4.0.16/src/Makefile.am.in    2010-11-24 
15:53:24.000000000 +0200
 <at>  <at>  -115,6 +115,7  <at>  <at>  else
  libsynthesissdk_la_SOURCES +=  <at> LIBSYNTHESISSDK_SOURCES_BOTH <at> 
  endif
  libsynthesissdk_la_CPPFLAGS = \
+       -fPIC \
         -D_GNU_SOURCE=1 \
         -include $(top_builddir)/config.h \
         -I$(srcdir)/Targets/ReleasedProducts/SDK \

Andris
Permalink | Reply | 3 comments |

Gmane