On Do, 2011-05-19 at 07:03 +0100, knipp(a)m-otion.com wrote:
Hi Patrick! Hello to all!
I read the list since several months, but I must have overseen one point
about the new CardDAV and CalDAV capabilites.
Will the new version synchronise Evolution to a CardDAV/CalDAV server?
Yes.
The synchronization is "SyncEvo backend A" <-- local sync --->
"SyncEvo
backend B".
A can be EDS and B can be CalDAV or CardDAV, thus giving you what you
want.
B can also be the file backend. That can be used to mirror Evolution
contacts in vCard 2.1 format (something not possible via the
import/export facilities).
Will the new version synchronise my Bluetooth SyncML device to a
CardDAV/CalDAV server?
In theory this would be possible. The CalDAV/CardDAV backends could be
used instead of Evolution in a normal SyncML config. In practice, this
approach fails because the CalDAV/CardDAV backends need configuration
options (syncURL, username/password) that are not available to them in a
normal SyncML session.
In local sync, they are stored in the "source-config@<source context>"
configuration.
But it is worth thinking a bit more about this. The "source-config"
syncURL could be used only for the initial database discovery; once the
"database" field of the backend is set to the final URL of a WebDAV
resource, the syncURL would no longer be needed. The credentials could
be stored in the databaseUser/Password properties and be shared with the
rest of the system via the new "shared credentials" proposal (see the
"configuration of CalDAV/CardDAV" thread).
Note that this could also be used inside SyncEvolution acting as a
SyncML server which directly stores the data in a CalDAV server.
May I use the new version to synchronise my application using the
XMLRPC
backend to a CardDAV/CalDAV server?
Yes, just use your XMLRPC backend instead of EDS.
Would it be possible to synchronise a SyncML server to a
CardDAV/CalDAV
server?
Same problem as with SyncML device.
--
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.