Re: [SyncEvolution] [REVIEW REQUEST 0/7] PBAP backend proposal
Hi Patrick,
On 02/01/2012 04:03 PM, Patrick Ohly wrote:
On Di, 2012-01-31 at 14:34 +0100, Mikel Astiz wrote:
> Hi Patrick,
>
> 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. I'm not sure how this would fit into
the Synthesis engine though. Just my 2 cents.
It's still a pretty big hack at the moment, but I am confident
that it
can be made to work without breaking anything else. I have to put it
aside now, though, and do some other work first - like preparing my
presentation for FOSDEM. You are not going to be there by any chance?
No problem, so far you've been more than helpful enough! I can think of
several workarounds we can use in the meantime, so there's no hurry at all.
Regarding FOSDEM, I won't be there unfortunately but I'm looking forward
for the recordings.
Cheers,
Mikel