On 08/04/2014 18:21:35, "Patrick Ohly" <[email protected]> wrote:
The settings of a data source are not limited to just three properties.
Currently defined are:
syncevolution --source-property ? | grep -v '^ '
sync (disabled, unshared, required)
uri (no default, unshared)
backend (select backend, shared)
syncFormat (no default, unshared)
forceSyncFormat (FALSE, unshared)
database = evolutionsource (no default, shared)
databaseFormat (no default, shared)
databaseUser = evolutionuser (no default, shared), databasePassword =
evolutionpassword (no default, shared)
OK, sweet.
Some of these (the unshared ones) are only relevant as part of a sync,
the others (the shared ones) are also relevant for just the data
access.
OK, good to know.
Correct. <config> basically is a place holder for lots of things.
That's part of what makes the manuals and HOWTOs hard to understand. For
a new user, it's very hard to figure out what concept is in play.
Except that the <config> has to be given, even if it is empty. That's
because the position of the non-keyword parts of the command line
matter: the first non-keyword is the config, the rest are source names.
So omitting it entirely won't fly. Good, that makes things easier.
Perhaps more examples would help. <shrug>
I don't actually think more examples are needed. I think the examples
might be aligned better not to implement any specific goal, but
specifically to highlight concepts. That's what I'm working towards now.
>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.
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.
We just have contexts, data
sources and sync configs. What is meant with "enable access" above
BTW?
Consider a SyncML client talking to SyncEvolution as a SyncML server.
Which data sources is that particular client allowed to access via
SyncML? The answer may be different for different clients, so that's
"enable access" via the sync property of the client controls.
Alright! Now I get it!
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.
Could they all have been defined in a single context? What would have
been the pros/cons of that?
They could have. The advantage of a single context is that one can do
"syncevolution --remove @google" and get rid of everything related to
Google. The disadvantage is that in a setup where you have one local
system address book that gets synced with multiple peers, having the
data source for that address book under "@google" would be inconsistent
for the other peers.
OK, good. I was just trying to understand how these contexts can be
used, I didn't have any plans for them other than the use you showed
before.
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!
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>?
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?
Ah no I understand that, but can a single command set up multiple
data
sources?
Yes. I think I mentioned the syntax already in this thread, but I don't
remember when.
--configure backend=eds-events @default calender
and
--configure backend=eds-contacts @default addressbook
can be combined into
--configure calendar/eds-event \
addressbook/backend=eds-contacts \
@default addressbook calendar
Okay... it's good to know that this can be done, and it answers my
question, but it maps
--configure backend=b1 @context s1
--configure backend=b2 @context s2
to
--configure s1/b1 s2/backend=b2 @context s2 s1
for which I can't readily see a rule governing the transformation, so
I'll take this as noted and stay away from it in my HOWTO.
Regards,
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
