[SyncEvolution] SyncEvolution in Fremantle

[Ove Kaaven]

Patrick Ohly skrev:
> I was planning to do a 0.9.2 update release in a few weeks. Should we
> merge your code and include the Maemo support in the release
> announcement?

If you want.

Is the debian/ dir in the sources maintained, anyway?

> The "Contributions" section in http://syncevolution.org/development
> covers the copyright handling policy in the project. There are different
> options, ranging from "do with the code what you want" to "use it under
> this open source license", so I hope you'll find this agreeable. The
> only limitation is that for small patches of core code, the copyright
> waiver would be preferred.

It's not clear from the website whether this "Linux Foundation license
agreement" is really to be sent to the moblin guys, or to some other
address. (Presumably, syncevolution isn't part of moblin.)

> 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?

>> However, the binary package is probably fairly ready for testing. It is
>> compiled with optimization,
> 
> Did you find out what the problem was with optimization? We compile with
> -Wall -Werror when using g++ 4.3/4.4, but only on i386/amd64, not arm.

Not really, after I started messing with 0.9.1 it worked, and I didn't
bother looking further, given the long cross-compile times. I suspect
compiling with --enable-shared made the problem go away, but I haven't
confirmed that by testing various combinations.

>> 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

- Do I need to worry about getSupportedTypes() or anything

- 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?

- 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?

>> Wasn't sure what URI scheme to use to let the user configure which
>> calendar to sync, for now I've settled on "id:<calendar ID>", and
>> defaulting to the same calendar that Nokia PC Suite would sync to.
> 
> Is the calendar ID something random or chosen manually when creating the
> calendar? I'm asking because "client-test" expects to have access to two
> calendars names <prefix>_ical20_[12] where <prefix> is set with
> CLIENT_TEST_EVOLUTION_PREFIX. Not essential, but would be good for
> automated testing.

The calendar ID is an integer. It's probably assigned in ascending
order. The default syncable calendar has ID 1, the default private (not
synced) calendar has ID 2, and the default birthday calendar has ID 3.
If you create your own custom calendars, they'll get ID 4, 5, and so on.
This ID is only meant for database lookups, of course; in the N900
calendar, the name of the calendar is shown, not the ID. That name is
chosen by the user when creating the calendar, and stored in the
database along with the ID. It seems to me that this would probably
allow two separate calendars with the same name to exist, if someone
really wanted it.

I did write the code so that if the URI is not prefixed with "id:", then
it will try to look the calendar up by name. Perhaps I could have used a
"name:" prefix for that or something, but I wasn't sure what the best
way was. But I did not write code to let you create a new calendar.
Using file:// doesn't make sense since you can't give the
calendar-backend a file path, that's not how it works.

> Along the same line, does the Maemo calendar backend support opening a
> calendar file? All other backends support the file:// notation to open a
> specific file and create it if it doesn't exist yet.

It can import/export vcal/ical files, but you can't tell it where the
internal database is. That's hardcoded, and possibly something it
communicates with through dbus rather than direct file access. You can
only tell it which calendar ID/name to grab entries for from the database.