1. 27 Dec, 2012 2 commits
  2. 24 Dec, 2012 2 commits
  3. 26 Nov, 2012 2 commits
  4. 05 Nov, 2012 1 commit
  5. 29 Oct, 2012 1 commit
  6. 10 Oct, 2012 1 commit
    • Lukas Zeller's avatar
      SyncModeExtensions: added config flag <syncmodeextensions> that must be set in… · 8226bd49
      Lukas Zeller authored
      SyncModeExtensions: added config flag <syncmodeextensions> that must be set in config to enable non-standard sync modes to be added into config. This is because some servers fail to work when non-standard modes are present, so by default they are off now.
      
      Projects that rely on the sync mode extensions (SyncEvolution) must enable them explicitly in config now
      8226bd49
  7. 02 Oct, 2012 2 commits
  8. 01 Oct, 2012 2 commits
  9. 26 Sep, 2012 1 commit
  10. 22 Sep, 2012 1 commit
  11. 17 Sep, 2012 1 commit
  12. 15 Sep, 2012 1 commit
  13. 14 Sep, 2012 1 commit
  14. 10 Sep, 2012 2 commits
  15. 09 Sep, 2012 2 commits
  16. 07 Sep, 2012 1 commit
  17. 06 Sep, 2012 1 commit
  18. 05 Sep, 2012 16 commits
    • Lukas Zeller's avatar
    • Lukas Zeller's avatar
      Fixed merge artifact (missing comma) · 7afaf89a
      Lukas Zeller authored
      7afaf89a
    • Lukas Zeller's avatar
      Merge remote-tracking branch 'refs/remotes/plan44.ch/luz_rebased' into syncmlios · 1932159b
      Lukas Zeller authored
      Conflicts:
      	src/sysync/syncagent.cpp (cosmetic scource formatting only)
      1932159b
    • Patrick Ohly's avatar
      engine: override merge options · 77c4693e
      Patrick Ohly authored
      In caching mode, the local data is meant to be an exact copy of the
      client's data. If the client removes fields in an item and then does a
      slow sync, no fields of a matching server item are meant to be
      preserved (= merged).
      
      This can be achieved with merge=no in the field list. But the field
      list is static and shared between data stores, which might not all
      operate in caching mode. This makes updating the config cumbersome.
      
      Therefore this patch adds a flag to the merging functions instead
      which overrides the configured behavior such that fields are always
      copied from one side into the other. This is activated when in caching
      mode and also (optionally) via the MERGEITEMS() function.
      
      The comparison is still needed, to determine whether anything changed
      at all during a slow sync and prevent unnecessary database writes.
      
      The loosing side is always the server in caching mode, no need to
      check (similar to making the local store read-only).
      
      This all applies to "slow sync" and "conflict" code paths.
      
      In caching mode, a <mergescript> is currently ignored in favor of
      doing the intended copying directly. Needs to be fixed.
      77c4693e
    • Patrick Ohly's avatar
      engine: ignore unassigned entries at end of array · 840c95e4
      Patrick Ohly authored
      The engine treated an array with unassigned entries at the end as
      larger (and thus different) from an array that ends before those
      entries, although reading those entries would also have return
      "unassigned".
      
      This caused the engine to treat items as different although there were
      semantically identical. Found while testing caching mode with
      SyncEvolution, where it is critical to minimize writing to the cache.
      
      The new code checks the larger array to see if all the extra entries
      are unassigned, in which case it returns "equal" as result instead of
      the previous "larger" or "smaller".
      840c95e4
    • Patrick Ohly's avatar
      engine: initial support for caching of remote data · 9c4f83ce
      Patrick Ohly authored
      This patch introduces support for true one-way syncing ("caching"):
      the local datastore is meant to be an exact copy of the data on the
      remote side. The assumption is that no modifications are ever made
      locally outside of syncing. This is different from one-way sync modes,
      which allows local changes and only temporarily disables sending them
      to the remote side.
      
      Another goal of the new mode is to avoid data writes as much as
      possible.
      
      This new mode only works on the server side of a sync, where the
      engine has enough control over the data flow. It has to be enabled in
      an <alertscript> with the new SETCACHEDATA() method, similar to the
      way how local read-only mode gets enabled with SETREADONLY(). A
      CACHEDATA() query method also gets added.
      
      A SyncML client cannot enable caching mode when alerting the server,
      nor can the server alert a client in that mode. The intended usage is
      that the caching mode is configured in the layer above the engine and
      then gets enabled in the engine after initiating a normal slow or
      incremental sync.
      
      Once the mode is enabled, the SyncML server behaves differently as
      follows:
      - The local sync set is always initialized, even in refresh-from-client
        syncs. That's because the data is intended to be reused during
        refresh-from-client syncs.
      - A refresh-from-client is treated like a slow sync: the mapping is
        cleared and remote items are matched.
      - After receiving and matching all remote items in a slow sync or
        refresh-from-client sync, any local item that was not matched
        (= its status is still "to be added remotely") gets deleted
        because it no longer exists on the remote side.
      
      The behavior of matching items in caching mode still needs to be
      changed to achieve the desired behavior. This is in a separate patch.
      9c4f83ce
    • Patrick Ohly's avatar
      engine: updated logging of sync keys · a781b669
      Patrick Ohly authored
      The additonal logging helped to understand that the sync keys
      provided by a datastore are not getting updated during a one-way
      sync.
      a781b669
    • Patrick Ohly's avatar
      SyncML TK: don't read past end of buffer · 9b5e2531
      Patrick Ohly authored
      The code which dumps the buffer after a parsing error had no way
      of obtaining the buffer size and thus read past the end of the buffer,
      as seen in SyncEvolution nightly testing under valgrind.
      
      Must provide the buffer length together with a pointer. The extra
      information is optional, so only the places which needed to know
      the length were updated.
      9b5e2531
    • Patrick Ohly's avatar
      engine: allow text->VJOURNAL conversion · b79d1f13
      Patrick Ohly authored
      SyncEvolution uses the Synthesis engine to convert a plain text memo
      to iCalendar 2.0 in the local storage. This is done like this:
      
      - define a text datatype which uses the same field list as calendar
      data:
      
          <textprofile name="JournalText" fieldlist="calendar">
            <linemap field="SUMMARY">
              <numlines>1</numlines>
              <inheader>false</inheader>
              <allowempty>true</allowempty>
              <filterkeyword>SUMMARY</filterkeyword>
            </linemap>
            <linemap field="DESCRIPTION">
              <numlines>0</numlines>
              <inheader>false</inheader>
              <allowempty>true</allowempty>
            </linemap>
          </textprofile>
      
          <datatype name="journaltext10" basetype="text">
            <use profile="JournalText"/>
            <typestring>text/plain</typestring>
            <versionstring>1.0</versionstring>
            ...
      
          same for text/plain 1.1
      
      - The "calendar" profile was extended to support VJOURNAL.
      
      - The incoming script of "journaltext10" sets ISEVENT in
        the "calendar" field list so that the data is marked as "journal".
      
      - define a store which supports iCalendar and plain text:
      
          <use datatype='icalendar20' mode='rw' preferred='yes'/>
          <use datatype='journaltext10' mode='rw'/>
          <use datatype='journaltext11' mode='rw'/>
      
      The problem with that is:
      1. A text/plain item from the peer is parsed and turned into
         an item with TTextItemType (corresponds to "journaltext10").
      2. Before writing into the local storage,
         MAKETEXTWITHPROFILE("vCalendar", 2) is called.
      3. For the value of VERSION, that method calls
         TTTextItemType::getTypeVers() =
         TSyncItemType::getTypeVers(), which returns the configured
         1.0 (from "journaltext10").
      4. The backend fails to parse the generated item because it
         only supports iCalendar 2.0 and is given something which
         has VERSION:1.0 (and iCalendar 2.0 encoding rules).
      
      The "fix" in this patch is to extend TTextItemType specifically for
      the case where getTypeVers() is called with a non-zero mode. I checked
      the source, that should only happen when used in combination with a
      MIME profile, something which only SyncEvolution does. I had to
      hard-code the support for iCalendar 2.0 (aMode = 2) and vCalendar 1.0
      (aMode = 1), something that IMHO does not really belong into
      TTextItemType.
      b79d1f13
    • Patrick Ohly's avatar
      autotools: must link against libpthreads · d04818f5
      Patrick Ohly authored
      Some libpthreads functions are called directly, and therefore
      libsynthesis should be linked to it directly. Otherwise it
      depends on other libs or executables loading that library,
      which can fail.
      d04818f5
    • Patrick Ohly's avatar
      CtCap: Funambol workaround · 4d458ac4
      Patrick Ohly authored
      Reduce number of non-standard sync modes in SyncCap by one if
      possible, to stay below what looks like a hard-coded limit for the
      number of SyncCap entries in the Funambol OneMedia server.
      4d458ac4
    • Patrick Ohly's avatar
      sync client: made sync mode choice configurable · f7378050
      Patrick Ohly authored
      libsynthesis has traditionally implemented "refresh-from-server" as
      "delete local data" plus "slow" sync. This is more compatible, because
      some servers did not support "refresh-from-server".
      
      But it has the downside that the server cannot know that the client
      won't send any data, and Funambol now only allows one slow sync before
      blocking the next one for a certain period of time. Probably this is
      done to prevent excessive resource usage by badly behaving clients.
      
      This commit introduces a new configure option called
      "<preferslowsync>yes/no</preferslowsync>". It goes into "<client>" and
      defaults to "yes", the traditional behavior.
      f7378050
    • Patrick Ohly's avatar
      SyncCap: compatibility enhancement for Nokia phones · fe040854
      Patrick Ohly authored
      It turns out that Nokia phones don't like SyncModes that they don't
      recognize. They abort a sync over Bluetooth/OBEX with a generic
      "Forbidden" error at the OBEX layer. This only occurs when the sync
      app requests the inclusion of non-standard SyncCaps ("can restart",
      custom flags).
      
      As a workaround, the extended SyncModes are sent less often now:
      - a client always sends them, based on the observation that
        servers handle that okay(ish - see Funambol workaround)
      - a server only sends them if the client has already sent
        some extensions itself
      
      This works as long as the Put with the client's DevInf is processed
      before the server's DevInf is generated in response to a Get; for
      libsynthesis<->libsynthesis syncs that is the case.
      
      A new dummy 390002 SyncMode is always sent, to trigger this behavior
      in the server also when the client has no other extensions. Perhaps
      this behavior should be made configurable and off by default, to avoid
      regressions in combinations which haven't been tested yet.
      fe040854
    • Lukas Zeller's avatar
      engine: item counting corrected (before, items that could not be sent in the… · 708a9e44
      Lukas Zeller authored
      engine: item counting corrected (before, items that could not be sent in the current message and were queued for the next message were not counted in the statistics and also not reported via pev_itemsent progress event)
      708a9e44
    • Lukas Zeller's avatar
    • Lukas Zeller's avatar
      Engine Version 3.4.0.44 · 7a63217d
      Lukas Zeller authored
      7a63217d