On Sun, 2013-01-20 at 17:12 +0000, Gary wrote:
Patrick Ohly <patrick.ohly@...> writes:
> Right. Now also set databaseUsername and databasePassword for "@Google
> calendar".
>
When you say add databaseUser and databasePassword, do I add these in
the same line that I define the google calendar target-config settings as
well as the database= and password= items?
So, something like:
syncevolution --configure calendar/backend=caldav
username=<my google user>
password=<my google password>
calendar/database=https://www.google.com:443/calendar/dav/<calendarID>/events
databaseUser=<my google user>
databasePassword=<my google password>
target-config@Google calendar
Basically this is right. It can be made a bit simpler, though. Because
you specify one source to configure (the "calendar" part after the
"target-config@Google" config name) one can leave out the "calendar/"
prefix. And because backend, database, databaseUser/Password are source
properties which are independent of the config, the "target-config"
isn't used. This leads to:
syncevolution --configure backend=caldav \
database=https://www.google.com:443/calendar/dav/<calendarID>/events
\
databaseUser=<my google user>
databasePassword=<my google password>
@Google calendar
Not sure I understand why I need to add it twice?
That's because strictly speaking, the "oracle@Google" config and the
"@Google calendar" source are independent of the
"target-config@Google"
config. You don't even need to configure the target-config for your use
case. You can do it and use it for operations like "--print-databases",
but it is not required for SyncML.
One could have added rules like "look for target-config in the same
context to find the right username/password", but that wouldn't have
been obvious either.
> > 2) Create a sync profile that connects to the Oracle
Calendar...
>
> No. Instead do it as quoted above.
>
So, like this:
syncevolution --configure username=<my oracle username>
password=<my oracle password>
syncURL=<oracle calendar address>
uri="./Calendar/Events?/dr(-14,60)"
oracle@Google calendar
Right.
If I ONLY ever want to copy events from oracle to google, am I right
in
assuming sync=one-way-from-server is correct here?
Not sure I now know which end is regarded as client and which as
server!
That's why these names were deprecated and replaced with "from-local"
and "from-remote". "local" is the data as defined via the backend
+database properties in the "calendar" source, "remote" is the
SyncML-side.
What you want is "one-way-from-remote"; "one-way-from-server" is also
correct and still recognized.
Also assuming here that because I have named this oracle@Google, it
knows
to use the target-config@Google as the 'other' end of the sync?
No, it doesn't use that. It uses the information in the "calendar"
source to instantiate a backend which reads/writes data via CalDAV as
part of a SyncML sync with Oracle.
The reason why the documentation describes the "target-config" thing is
partly historic (that's what was implemented first), partly because it
allows setting up/testing the CalDAV source independently of SyncML.
And to run the sync I run
syncevolution oracle@Google
Right.
--
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.