On Do, 2012-02-02 at 15:39 +0100, Mikel Astiz wrote:
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.
Absolutely. Part of the currently missing checks in the engine is
whether the source supports the extended behavior.
It will also be useful to check whether the source really needs a second
pass. Adding new callbacks to the API is difficult. I can imagine that a
special (non-)error code from the end-data-write callback (aka endSync()
in SyncEvolution) could be used for that.
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.