Re: [SyncEvolution] New backend for integration with web applications
On Tue, 2009-12-01 at 12:08 +0000, knipp(a)m-otion.com 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.