Re: [SyncEvolution] [REVIEW REQUEST 0/7] PBAP backend proposal

On 02/01/2012 04:03 PM, Patrick Ohly wrote: > On Di, 2012-01-31 at 14:34 +0100, Mikel Astiz wrote: >> On 01/31/2012 08:38 AM, Patrick Ohly wrote: >>> I'm currently thinking about that myself. There are other use-cases for >>> it, for example the issue with the SyncML client side detecting that it >>> has more changes pending at the end of the normal sync. I'm leaning to >>> extend the internal SyncML session so that both sides just enter further >>> send/receive cycles until no further changes need to be transmitted. >> That seems very interesting indeed for our use-cases. In this case the >> requirement would be that the backend is able to keep some context >> (session) from one pass to the next. > The goal is to only instantiate the SyncSource once. Any context (like a > handle for the current PBAP session) can be kept attached to it and then > be reused for multiple beginSync()+read/writeItems()+endSync() cycles. > The SyncSource must be prepared for this change of semantic and update > the changes that it reports when beginSync() is called again. > > I've done some experiments with the Synthesis engine and got to a state > where more than one internal sync session was possible using the same > engine and source instances. Because the source wasn't prepared for it, > the second sync session promptly deleted all data... ;-) To avoid breaking existing code, another approach could be that the syncsource interface is extended, with methods that report if there are pending passes for this source. That would hopefully avoid having to modify all existing source types.