On Tue, 2012-08-07 at 08:52 +0200, Ove Kåven wrote: > On 06. aug. 2012 12:16, Patrick Ohly wrote: > > If you look at adding support for notes, then I suggest that you do it > > based on 1.2.99.x. > > Yes, I was going to anyway, of course. (Though it turned out that the > new code and build system took a heck of a lot of work to manage to > build on Maemo. A whole weekend spent just on that, patching .cpp files > that don't build with g++ 4.2, patching configure to check for missing > headers and other stuff, debugging linking failures, and whatnot.)
Sorry to hear that. I check compilation with a range of compilers, but 4.2 is indeed not among them. The oldest is 4.4, the default on Ubuntu Lucid. I could add 4.1, which is available in Lucid. Please send me your patches when you are done, then I'll add them in a post-1.3 release and also add the compile check. > There's one question I have about the change tracking in KCalExtended. > In beginSync, you ask the database for all modifications done since the > previous anchor. In endSync, you generate an anchor based on the current > time when endSync is called. Wouldn't this risk losing any local changes > done by the user *during* the sync, between beginSync and endSync? You've nailed it. This is exactly the problem and one reason why I am not a fan of such time-based change tracking. The other is that it assumes that time never goes backwards, which is not guaranteed to be true in all cases. The user might run a sync with a bad system clock, set the clock, then do another sync. > Would > it be safer to generate the anchor in beginSync, so if the user does > anything during the sync, the next sync can catch it? Then changes made by SyncEvolution after beginSync() would be reported in the next sync as changes which need to be transmitted to the peer, which would be wrong. -- 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. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
