Hello Ove! Thanks a lot for this nice Christmas present!
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? Publishing your code in a publicly visible git repository was mentioned. For complex, long-lived branches of the code (say, a backend which cannot be merged) this is a good approach, but in this case it would be easier to just merge your changes into the normal SyncEvolution repo - then there is no doubt about what the latest revision is and we can prevent bit-rot by compiling it regularly. For releases we would still depend on external help. 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. 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. > 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. > 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? > 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. 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. On Thu, 2009-12-24 at 12:23 +0000, Ove Kaaven wrote: > It's about one of the config options ("evolutionsource"). If you've used > the calendar program, you may have noticed that you can choose what > calendar to insert events and stuff into, even create new calendars. > (The "N900" and "Private" calendars exist by default.) Only one such > calendar can be synced, and you can configure which one (or be happy > with the default, which happens to be the "N900" calendar) This is primarily a limitation of the existing SyncML servers. ScheduleWorld has some ways around that, see their Wiki for details. SyncEvolution can have multiple calendar sources, as long as server URI and local database are not shared between sources. On Thu, 2009-12-24 at 12:23 +0000, Ove Kaaven wrote: > From what I understand, the syncevolution developers are working on > implementing a desktop SyncML server, which would allow you to cut the > middleman. I don't think they're quite there yet, though. Depends ;-) 1.0 alpha 1 is available and should be up to the task. In this case, the HTTP server script would have to be used: http://syncevolution.org/development/http-server-howto -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
