On Sat, 26 Dec 2009, Ove Kaaven wrote: My comments for your reference. > > On Thu, 2009-12-24 at 08:03 +0000, Ove Kaaven wrote: > >> It can't yet be built with a buildbot, primarily because not all of its > >> build-dependencies exist in maemo-devel, cppunit in particular. > > > > This shouldn't be a hard dependency. Without cppunit, "client-test" > > can't be built, but that is not necessary during normal usage. If you > > ran into a compile problem without cppunit, then please file a bug > > report. > > src/backends/evolution/Makefile.am and src/backends/file/Makefile.am > both enforce -DENABLE_INTEGRATION_TESTS flag regardless of how the > source is configured. This doesn't seem to cause a run-time dependency, > but it definitely causes a compile-time dependency when --enable-shared > is used (not with --disable-shared, since only the *Register.cpp files > actually includes test.h). So I should go to bugzilla with that? That indeed looks like a bug. I will look at this further, thanks for your report! > > >> via the Maemo-Calendar backend which I've > >> spent the last two days writing > > > > I'm glad to hear that you got this working without too much effort. Any > > suggestions about improving the available documentation to make backend > > development easier? > > Not sure. I did find all the sync source stuff a bit confusing and badly > documented. Especially since it's been years since I last programmed C++ > (I had started to agree with the C++ detractors, it's a *really* messy > language, and it still remains the case that any C++ framework you > didn't design yourself can be quite difficult to get into). > > I can't quite recall exactly what confused me the most as I wrote the > backend, but there are still a few things I'm unsure of: > > - I'm not sure how to properly write those integration tests in the > *Register.cpp Maybe we need to add some documents on the HACKING guide. > > - Do I need to worry about getSupportedTypes() or anything No, you don't (at least at the moment). The code is clearly not used but I don't know why it is created, maybe Patrick knows the history. > > - The Maemo's calendar-backend can return entries that have changed > after a particular date (typically you'd use the time of the previous > sync). Is there a way to use this to improve on the TrackingSyncSource > method, so it won't be necessary to load and generate revision strings > for the whole database every time? If your backend supports change tracking by itself, then you don't need to use TrackingSyncSource (which mainly implements change tracking facility via revision checking). You may refer to the SQlite backend for reference. > > - The Maemo addressbook (which is still ebook-based), as well as the > calendar (which has APIs to convert to vcal 1.0 and ical 2.0), stores > some non-standard fields. I noticed something on the SyncEvolution > webpage about mimeprofiles to specify what fields are stored locally. Is > there a way to specify that, so that these fields are not destroyed on > the Maemo device when syncing with a server that doesn't support them, > even though the backends do convert from/to the standard vcard and ical > formats? > My understanding is it's not possible with current SyncSource API. GetSynthesisInfo provides the opportunity to let the Backends provide specific configuration information but that does not covers the remoterule for datastore. _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers
-- Regards, Chen Congwu Moblin China Development _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
