On Tue, 2009-12-01 at 07:35 +0000, knipp(a)m-otion.com wrote: Excellent! I was always hoping that someone would do that. Congratulations for being the first one :-) Given your complete lack of questions, may I assume that you found the available material sufficient to accomplish what you wanted to do (okay, except for the questions that your raised below)? If not, any suggestions what could be improved, and how? Yep, TrackingSyncSource certainly is the best starting point for something like this. It might get a bit more challenging when looking at the advanced issues in sync: data conversion and format description. Right now, you probably use the vCard and vCalendar/iCalendar profiles that come with SyncEvolution and your web service works with the same kind of items as Evolution. There are existing methods as well as unimplemented ideas for making this more flexible. Let me know if you want to know more and we can dive more deeply into this. If it compiles for you, it should compile for us, once we install the necessary development files for the new library dependencies. That depends on a bit on how often you want to send updates. If it is infrequent, then "git am-format" from your private repo and attaching the result to a Bugzilla entry is the preferred method. If it is frequent, then we have to look at different methods, either by giving you write access or pulling from a repo that you publish somewhere (github and gitorious are some free options). We also need to discuss another aspect: copyright ownership. Right now, all patches submitted via Bugzilla for SyncEvolution must be covered by this copyright waiver: http://bugzilla.moblin.org/waiver.html Would that be acceptable for you? For large submissions it might even become necessary to sign a more formal agreement. As you are the first one to actually offering something, I need to check first what the current conditions are. My own goal was to only have such a waiver or transfer for core code and let backends be contributed under any suitable license. Is that something that I should push for? I can't guarantee that it'll get through inside Intel, but I can certainly try. For the time being, can you publish your work in a public git repo? Then we can look at it while discussing how to merge it. Right now all that we have is plain ASCII. There is an issue about using a richer format for user documentation: http://bugzilla.moblin.org/show_bug.cgi?id=4633 So far, this was always low enough priority that it never got worked on. If you have suggestions, feel free to bring them up. Right now, the environment variable CLIENT_TEST_EVOLUTION_SOURCE can be set to a certain prefix, like "file:///tmp/test_". The name of the data (ical20, vcard30, ...) and the numbers 1 and 2 are appended to form unique evolutionsource values. For example, with the prefix above, /tmp/test_ical20_1 and /tmp/test_ical20_2 would be used for tests which require two local databases. Two local databases are required for several of the Client::Sync tests, for example for copying items from client A to the server and back to client B. The way how evolutionsource is composed can be changed. For example, we could turn CLIENT_TEST_EVOLUTION_SOURCE into a printf format specifier. For details, see src/client-test-app.cpp. What format do you need? -- 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.

On Tue, 2009-12-01 at 12:08 +0000, knipp(a)m-otion.com wrote: That's not currently possible with the Synthesis engine: http://bugzilla.moblin.org/show_bug.cgi?id=5046 "raw file sync source" This could be changed, but then we get into another problem: a SyncML server needs to know what kind of properties its client supports [1]. This is not the data conversion that you can do locally inside your own application, it is for the conversion happening remotely. Currently, the Synthesis engine provides that information ("DevInf") automatically based on the data format conversion that it was configured to use. If we remove that conversion, that information must come from somewhere else. [1] http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard Another problem is that less advanced servers don't use the provided DevInf. Instead they match against some strings ("this SyncML client is SyncEvolution") and then use some hard-coded configuration. If your backend differs considerably from the one the servers expect from SyncEvolution, then we should find a way how SyncEvolution can identify itself differently depending on which backends are active. This is purely theoretic at this point; real interoperability testing with servers and you backend would be needed to see whether such a change and the corresponding server-side changes are necessary at all. That should go into the README, in the section on compiling from source. Good. Now I just need to check whether a patch of that size can be accepted under that waiver. There was some talk about it being meant for small patches, not large contributions, but I'll check that. -- 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.

Now, that I've finished the documentation, I saved it as README file and created the patch, filed as bug #8499 http://bugzilla.moblin.org/show_bug.cgi?id=8499 The new backend undergoes heavy testing at the moment, up to now the emerged problems laid outside of syncevolution and the new backend :-) -- NEUE MOBILNUMMER: +43 660 4859550 Franz Knipp, Dipl.-Ing. --------------------------------------------------------------------- knipp(a)m-otion.com +43 660 4859550 https://www.xing.com/profile/Franz_Knipp --------------------------------------------------------------------- m-otion GmbH Favoritenstr 4-6/III, 1040 Wien +43 1 205705 (Fax 99) --------------------------------------------------------------------- www.m-otion.com