On So, 2011-01-02 at 01:03 +0000, John Dykstra wrote:
I've been trying to use the Evolution databases as the backing
store on
the server side. However, I'm running into problems specifying the
evolutionsource property. It appears that evolutionsource can only be
specified in the default/sources directory, and is ignored if I specify
it in the peers/foo/sources directory.
There's no need to create multiple configurations per client. Just add
additional sources to it.
Here's how you can synchronize multiple databases per peer (using a second calendar as
example):
* on the server side, configure a second calendar in the default context:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
server> \
--source-property "type=Evolution Calendar" \
@default calendar2
* on the client, enable the second calendar:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
client> \
--source-property "type=Evolution Calendar" \
--source-property sync=two-way \
<config name> calendar2
* Now synchronize using the <config name> client config.
Is there a way that I can configure the server so that it uses the
Evolution database? If not, will the filesystem database allow me to do
what I need?
There's no difference between Evolution and filesystem databases in this
regard. Performance with filesystem is better, so unless you really want
your data in EDS on the server side, the filesystem storage is
recommended.
BTW, I updated the syncevo-http-server.py script. You can use the
current version from git with an existing SyncEvolution installation:
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/raw/maste...
Feedback on the new command line options and the new code in general
would be appreciated. I haven't updated the HOWTO yet, so just follow
"syncevo-http-server.py --help".
--
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.