On Tue, 2009-12-01 at 07:35 +0000, [email protected] wrote: > I've successfully finished an additional backend for syncevolution, > which connects to a web application using XMLRPC (using xmlrpc-c).
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? > The file backend was used as template for the new backend, therefore > TrackingSyncSource is used. > > Only four methods have to be implemented on the web application: > > * listAllItems > * readItem > * insertItem > * removeItem 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. > The URL for the web application as well as parameters like database, > username and password are configured using the evolutionsource > configuration parameter. > > Even I'm no automake/autoconf expert, I've adapted the respective files, > so that my changes should integrate into the current building process > without troubles. If it compiles for you, it should compile for us, once we install the necessary development files for the new library dependencies. > How would you like to integrate the new backend (which is a set of files > in their own backend directory) into the repository? May I push them back, > shall I send a patch? 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. > Which is the preferred way to make the documentation for the configuration > as well the XMLRPC interface description? 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. > How can I adopt the unit tests in a way, that a user configurable web > service can be set in the evolutionsource parameter? 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
