On Wed, 2014-04-09 at 07:27 +0000, Emiliano Heyns wrote:
> On 09/04/2014 08:48:27, "Patrick Ohly" <[email protected]> wrote:
>
> >> >> 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.
> This is easier to avoid (so far) in my HOWTO -- the thingie simply gets
> a very concrete name.
Yes, for a specific HOWTO that's easy. It gets harder when talking about
the abstract concepts.
> >> 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.
The main motivation is that (in most cases) it allows giving users a
single command which does everything necessary to set up syncing. The
exception is local sync, where one needs at least two commands. Whether
that flexibility is useful and/or necessary is up for debate. As Graham
said, he doesn't use the "<source name>/<property name>" syntax and
prefers to configure different sources with different commands.
> That would imply that
> 1. There is no property name that occurs both in --source-property and
> --sync-property (I looked and that seems true, but it would be good to
> know this is structurally true, not just incidentally), and
If there was an overlap, one could use --source-property or
--sync-property to disambiguate the meaning of an assignment on the
command line.
But because such an overlap would be confusing, it was avoided
intentionally.
> 2. No configure command can mix source and sync properties.
It can.
> 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. If no such source gets mentioned,
the "sync" property has no effect.
> >> > 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.
> 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.
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.
Nowadays I think it would be easier to avoid that feature in favor of
databaseUser=id:<config name> and storing username/password in that
config. That mechanism is newish (introduced in 1.4) and not documented
well enough at the moment, though.
--- Begin Message ---
On Fri, 2014-04-04 at 12:24 +0005, Khurshid Alam wrote:
> On Fri, Apr 4, 2014 at 2:22 PM, Patrick Ohly <[email protected]>
> wrote
>
> > syncevolution --configure \ printChanges=0 \ loglevel=3 \
> > syncURL=none \ target-config@google Remember that the command line
> > is doing sanity checks when creating new configs to catch typos, so
> > we have to confirm explicitly that this new config is meant to be
> > created without a syncURL. Now we need to enable access to the
> > main-google-addressbook. It would be inactive otherwise. This is
> > useful when configuring a peer in a context which has many different
> > sources defined, but you only want the peer to have access to a
> > certain subset of them. Any "sync" value other than "none" is okay
> > here. syncevolution --configure \ sync=two-way \
> > target-config@google main-google-addressbook
>
> Can this be done with a single command line?
>
>
> syncevolution --configure \
> printChanges=0 \
> loglevel=3 \
> syncURL=none \
> target-config@google main-google-addressbook
This is a valid invocation. However, it does not set any property in the
"main-google-addressbook" source. It will get created, but with all
properties unset.
More generally speaking, a "--configure" operation will touch all
configs (sync and source) that get named on the command line and ensure
that each sync resp. source property is set to one of the following (in
this order, weakest one first):
1. The default state of the property, typically unset => populates
new config.ini files with all currently defined properties and
their comments.
2. The current state of property (if the config already exists) =>
property does not change.
3. A value from the command line without explicit source name (e.g.
sync=two-way) => new value.
4. A value from the command line with explicit source name (e.g.
main-google-addressbook/sync=two-way) => new value.
> I omitted "sync=tow-way" parameter because it can be defined when we
> pair the sources....or can it?
The "pairing" via "--configure google@default" does not set properties
in the "target-config@google". So no, the "sync=two-way" must be set
separately there.
> > The next step is to set up the actual connection between @default
> > and @google. We want to choose sources explicitly, so disable all
> > sources which might be defined in the @default context:
> > syncevolution --configure \ syncURL=local://@google \ peerIsClient=1
> > \ sync=none \ google@default Then pair the sources. We are doing
> > that for only one pair of sources here, but it could also be done
> > for more. syncevolution --configure \ sync=two-way \
> > uri=main-google-addressbook \ google@default my-vcard-source
>
>
>
> So basically in first configuration, "sync=none" disables all sources
> in the @default (including my-vcard-source) & in 2nd configuration,
> it, again, enables nothing but "my-vcard-source" (via sync=two-way) &
> pairs it with main-google-addressbook.
Correct.
> This is kind of a roundabout way to me.
You would prefer to have nothing enabled by default?
We can do that, but then the "memotoo" use case in my email no longer
works.
> And why do we have to do everything with @default context? What if I
> configure without it:
>
>
> 1. syncevolution --configure \
> syncURL=local://@google \
> peerIsClient=1 \
> google my-vcard-source
>
>
> 2. syncevolution --configure \
> sync=two-way \
> uri=main-google-addressbook \
> google my-vcard-source
>
>
> 3. syncevolution google my-vcard-source
That's the same thing, because "google@default" = "google". I just
didn't want to use a short-hand notation in my examples because the
"@default" context is there, even if it doesn't get named explicitly.
> Here, as any other sources are not defined, they will simply remain
> inactive during the sync. Aren't they?
Correct.
> > And now sync: syncevolution --sync slow google@default syncevolution
> > google@default
>
> Lets say I also have a second source enabled in the @default context:
> my-vcard-source2
>
>
> So this command: "syncevolution google@default my-vcard-source2" will
> only sync my-vcard-source2. Right?
Right. It's a feature that naming one or more sources during a sync
operation temporarily selects this/these source(s) for the sync.
--
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.
--- End Message ---
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
