1:18 a.m.
On Mon, 2010-06-14 at 15:55 +0100, Nils Faerber wrote:
I am new to SyncEvo so please excuse if I am missing some older
info...
but browsing through the web-site, WiKi and mail archives I did not not
come up with some obvious answer to it, so here I go...
The emails from Franz Knipp/m-otion on their XMLRPC backend may be
relevant for your use case. Franz already wrote a backend which access
non-local data.
Background of my interest in SyncEvo is that we have to create a
connector for Gnome Evolution <-> Kolab groupware server.
I've seen your emails on the Evolution dev list.
Our first idea was to create an EDS backend plugin for this. While
this
is doable it also means to touch a lot of parts and EDS itself is
already not exactly the most comfortable field to start working in. And
above all the concept of attaching to the Kolab server does not really
match the EDS way of working (while e.g. Kontakt works on a local
"cache" that is "synced" to the Kolab server, EDS works on the
source
directly, i.e. it would directly 1:1 transfer the items to/from the server).
So we came to the conclusion that using SyncEvo to attach to the Kolab
server and have it sync with a local EDS or direct file store of the
Evolution client could be a better approach.
The point that is not entirely clear to me yet is if and how far a
non-SyncML backend could be added to SyncEvo?
It's definitely possible, see the reference to XMLRPC and its code in
SyncEvolution's src/backends/xmlrpc directory. There were some
shortcomings initially (like reading items multiple times), but this has
already been improved a bit and could be improved further.
The main reason why implementing your use case is a bit cumbersome is
that SyncEvolution does not yet support local sync between two backends.
At least one peer must be a remote SyncML peer, whereas you need Kolab
backend <-> Evolution backend.
You can work around this while we work on local sync like this:
* set up SyncEvolution as SyncML server, using the default EDS
backends (i.e. do not set "type") and context (@default):
http://syncevolution.org/development/http-server-howto
* set up SyncEvolution as SyncML client, using your new backend in
a second context (@kolab, with type set to select your backend)
* run HTTP server locally
* run client with "--daemon=no"
The contexts define the "local" database, therefore you need two of
them. --daemon=no is necessary because otherwise the client session
would block the syncevo-dbus-server and prevent running the necessary
server session.
This all should become a lot easier once SyncEvolution supports local
sync directly, either by hiding that two sessions are active or by
avoiding SyncML entirely.
Or would there be a better approach to do that? Again, keep in mind
that
installing additional components on the Kolab server is not an option...
This sounds very feasible to me. It would be a good incentive to really
tackle this local sync problem.
--
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.