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