On Tue, 2014-04-08 at 18:05 +0000, Emiliano Heyns wrote:
> On 08/04/2014 18:21:35, "Patrick Ohly" <[email protected]> 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.
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
