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
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
>> 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
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
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
Moblin China Development