On Tue, 2009-12-01 at 12:08 +0000, [email protected] wrote: > On Tue, 1 Dec 2009, Patrick Ohly wrote: > > 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. > > As our application will exchange vcards and icals not only by means of > SyncML, but e. g. also by mail, we had to build the flexibility inside of > the application. Therefore I'd like to turn off any conversion or mapping.
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. > > If it compiles for you, it should compile for us, once we install the > > necessary development files for the new library dependencies. > > On ubuntu or Debian: apt-get install libxmlrpc-c3-dev That should go into the README, in the section on compiling from source. > > http://bugzilla.moblin.org/waiver.html > > > > Would that be acceptable for you? > > Yes, absolutely. 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
