4:48 p.m.
On Tue, 2014-04-08 at 18:05 +0000, Emiliano Heyns wrote:
On 08/04/2014 18:21:35, "Patrick Ohly"
<patrick.ohly(a)intel.com> wrote:
>> >No. "my-vcard-source" is the source config in the
"@default"
>>context.
>> >Think of the context as a folder in a file system which can contain
>> >items of different types: source configs, sync configs.
>> >
>> OK, so config names (sync and source) are unique within a context,
>>and
>> source config names always identify a single data source. If there is
>>a
>> one-on-one correspondence between data sources and source configs,
>>why
>> do these exist as separate concepts?
>
>There is no real difference. As the terminology entry says, "data
>source" is "primarily used for the configuration which combines backend
>and database settings".
OK, so I could safely substitute 'source config' anywhere where I might
use 'datasource'. If that's the case, my HOWTO is going to use 'source
config' systematically.
Just using "source config" without defining "source" may leave some
users wondering what "source" is, though.
>> So a "peer" isn't really a SE concept, then?
>SyncEvolution did not invent the term, yes. It gets defined anyway, to
>make it clear in which meaning it is used.
OK, then my howto is going to drop the work 'peer' too.
Again, I suspect that avoiding the word will not be easy. Sometimes you
just have to give that thingie a name that you synchronize with, and
always saying "the server, phone, or other computer" gets tiresome.
>Fair enough. But then try to describe how these hierarchical
lookup
>would be configured and debugged ("Where did this value of loglevel
>come
>from?"). I suspect that it would get more complex elsewhere.
That's currently also hard, right? Because some properties can be
defined at more than one place. Anyhow, no biggie. It just describes my
personal preference.
At the moment, a property can only be set twice if you have independent
configurations. For a source "abc" used with a sync config "foo@bar"
the
"loglevel" exists only once, in "foo@bar". The hierarchical lookup
would
have allowed to set a loglevel in "abc", in "foo@bar", in
"@bar", and
perhaps even globally (i.e. shared between all contexts).
Because the property defines where it belongs, the command line doesn't
need to have a syntax for defining that. That would have to be added.
> And because it doesn't have a target-config, right?
Otherwise it would
>> have set up a target-config instead. Or is it the peerIsClient?
>>Because
>> it looks very similar to the command
>>
>> syncevolution --configure printChanges=0 loglevel=3 syncURL=none
>> target-config@google
>>
>> which set up the target-config. What exactly makes SE decide to do
>>one
>> or the other?
>
>Primarily the usage. A sync config is what you use when triggering a
>sync. That config then has to be set up correctly:
> 1. Must have a valid syncURL.
> 2. For a local sync, currently only peerIsClient=1 is valid. There
> is no meaning defined for peerIsClient=0 yet, but that might
> change, and therefore it is needed.
>
Right! So use determines whether it is a sync or a source config! A
config in and of itself is just a bag of properties!
Wait, I was talking about sync and target configs above. You are right,
a "config" is just a set of properties, but there is a difference
between "source config" and "sync/target config" that goes beyond
just
differnt usage, because there are two different set of properties that
can go into the former (--source-property ?) and the latter
(--sync-property ?).
This difference is enforced when setting properties. You cannot set a
sync property in a source config or vice versa.
>> OK, so if I do remote@local for simplification I can't
go wrong?
>I don't follow here.
If I am constructing a sync config (by Jove, I might be getting the
concepts right at this point!), would it be sensible to always name
these <a name that implies remote>@<a name that implies local>?
If the data is indeed local, then yes. I would name a context based on
the sources defined in it.
> Sorry; I meant to say "is this why I repeat the
credentials in the
>setup
>> of the datasource and of the sync config"?
>Repeating the Google credentials in the target-config is not necessary
>if they were already set as databaseUser/Password for the individual
>source(s).
And visa versa? If I define them in the target-config, can I omit them
for the source configs?
Yes. That was the original purpose of the "target-config": having a
place to store credentials.
That the WebDAV backends also support databaseUser/Password was added
later, to support using these backends in a sync config for a SyncML
peer where username/password must be used for credentials of that peer
and thus cannot be used as WebDAV credentials.
--
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.