Re: [SyncEvolution] [REVIEW REQUEST 0/7] PBAP backend proposal
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... ;-)
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?
--
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.