Hello! For the PBAP caching mechanism in SyncEvolution I'd like to use the Synthesis engine. I think that makes sense because the engine does a few things which would have to be done manually otherwise (translate between formats, finding pairs). The improvements below would also make sense in other use cases. At the moment the engine (or rather, SyncML) lacks a few things which I need to change. I'm focusing on one-way-from-client syncing because the server has a bit more control over what it does and because it matches the SyncEvolution use case. In SyncML, incremental one-way syncs fall back to a two-way slow sync after a failure. If the server has an item which the client no longer has, then the item will be recreated on the client, despite the intention to only transfer data in one direction. Right? This is undesirable in general (IMHO), and an absolute no-no for PBAP as the client, because it cannot write the changes. As a first step I would disable sending changes to the client if the client asked for a one-way-from-client sync. The server's datastore can already be marked read-only (<readonly> config option, SETREADONLY()); something similar for the peer's datastore would make sense. Then I could leave the default behavior as it is and use a script function to trigger the desired behavior. Actually, there is SETREFRESHONLY(). According to the docs, it is meant to be used for turning a two-way sync requested by the client into a refresh-from-remote. I need to check whether I can use that or still need to add/modify something. Suppose a slow sync was done in that modified refresh-only mode. Any item that the server has which are not on the client need to be removed if the server's storage is meant to mirror the client. At the moment, the engine cannot know whether it is meant to mirror the data and thus it will leave the extra items on the server unchanged. I intend to add a "<mirror>" config option similar to "<readonly>". If set, the engine will not only avoid sending changes to the client, it will also remove those extra local items. Finally, during a slow sync where a match was found, extra properties in the server's copy of an item must be removed to avoid keeping stale data. This can already be done by configuring the merging of items accordingly (instead of preserving as much data as possible, ensure that the client's item is always considered the "winning" one and that its version completely overwrites the server's). -- 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.