10:11 a.m.
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.