On 09/04/2014 10:03:32, "Patrick Ohly" <[email protected]> wrote:
Yes, for a specific HOWTO that's easy. It gets harder when talking
about
the abstract concepts.
That is true, and I'll probably re-introduce the term at some point. My
main focus of the HOWTO is not to overload the reader and only hand her
the concepts that are strictly required for a specific example. There is
already much going on even in that restricted setting.
>> 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.
Ah damn, I just thought I had a handle on things. So does SE
determine
whether you intend to configure a sync or a source config by looking
at
which properties you pass on the command line?
I explained that in my email to Khurshid (attached again). The key
point
is that "--configure" modifies *everything* mentioned on the command
line. It's not configuring either sync or source config. Instead it
does
both at the same time.
OK, so let me see if I have got it now:
1. A config is a typed bundle of properties. It is either a sync config
or a source config. Which of these two it is depends on its position on
the command line on first use, but it cannot be changed after creation
2. In any given invocation, syncevolution decides what properties go to
the source or sync config(s) on the command line based on whether they
"belong" to one type or the other. Naming ambiguities can be overruled
by specifying --(source|sync)-property, but the current names are
distinct so there is no practical need to do so right now.
3. Properties provided during invocation that do not have a
corresponding config kind provided are silently ignored
4. Certain config/property combinations are enforced, like
sync-config/syncURL
In the synopsys, target-config is being explained in terms of being a
special kind of sync config, But when configuring it, I can pass it a
sync= parameter, where the sync property is a source property, not a
sync property. How should I see this?
The "sync" property will get set for "target-config" in the sources
named together with the target-config.
So the target-config is considered to live inside the data source? A
context contains data sources contains target-configs? And if the
target-config hosts the sync property, it's also (in addition to being a
kind of sync config) a kind of source config it seems. Which properties
can a target-config hold?
If I were two sync two paired sources, that would allow for 4 places
where a sync property could be set then? What are sensible combinations?
If no such source gets mentioned,
the "sync" property has no effect.
OK so to set up the sync property the command line must name a data
source and one of its target configs.
>Yes. That was the original purpose of the "target-config": having a
>place to store credentials.
And we have target-configs attached to data sources because a data
source might be accessed with differing credentials. Correct?
I don't follow here.
I was wondering why there would be a target-config in addition to a data
source when the data source seemed to hold everything you'd need to
access it. But if the data source would be, for example, a calendar
hosted at google, that would be identified by the sync url and backend;
multiple credentials could be used to access that data source; those
could live in a target-config attached to the source.
The credentials in the target-config are useful if (and only if) you
have multiple sources in the same context as that target-config which
share the same pair of username/password values. It was meant to avoid
duplication of information.
But then my interpretation above doesn't seem to be the correct one.
It's more about credential-sharing across data sources. But then my
mental picture of 'The "sync" property will get set for "target-config"
in the sources' above must be wrong.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
