Patrick Ohly skrev:
I was planning to do a 0.9.2 update release in a few weeks. Should
merge your code and include the Maemo support in the release
If you want.
Is the debian/ dir in the sources maintained, anyway?
The "Contributions" section in
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
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.
> 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
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
- 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
> Wasn't sure what URI scheme to use to let the user configure
> calendar to sync, for now I've settled on "id:<calendar ID>",
> 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_ where <prefix> is set with
CLIENT_TEST_EVOLUTION_PREFIX. Not essential, but would be good for
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
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.