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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
