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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
