On 15/09/14 16:19, Patrick Ohly wrote:
This is the first release candidate for 1.5. No further changes are
planned except for fixing yet-to-be-discovered bugs - so find them
The (new in this release, I think) checking for mixing shared/unshared
properties is causing me some logical confusion. Here is (the outline
of) how I used to configure my Exchange server config:
1) Remove the existing configurations
2) syncevolution --configure --template none backend=eas-contacts
database=Contacts username=my-account-name @Exchange contacts
3) syncevolution --configure --template none username=my-account-name
password= printChanges=1 loglevel=4 target-config@Exchange
4) syncevolution --configure sync=two-way uri=contacts loglevel=4
The second step now gives the error:
[ERROR] per-peer (unshared) properties not allowed: username
If I remove the username, it gives the error:
[ERROR] contacts: backend failed: fetching folder list:
GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find
The only way I can get it to work is if I bring step 3 to be in front of
step 2. That works, but feels wrong (it also breaks my scripts in a
hard to fix way, but that is my problem). It feels like there should be
one of two cases:
i) The context (@Exchange) is associated with a particular account. In
that case, the account id should be a property on the context, not on
ii) The context (@Exchange) is generic for several activesync accounts
(different users), in which case the folder mappings cannot be checked
at the time they are set up. Not very user friendly.
To me, option (i) seems more logical as well as much more user friendly.
But then the account can't be a per-peer property (which peer do you use?).
This might be because we are misusing the username property to provide a
convenient way to specify the activesyncd account -- although I don't
really understand what is wrong with that. I also don't understand how
other backends deal with similar problems. Surely a Google server is
accessed using some credentials and they are either properties of the
context or the peer, with the same issues?
We could, of course, just stop using username and embed the account name
in the database name. It would be a bit tedious to type (as account
names are usually actually email addresses, although they don't have to be).
There seem to be two problems here:
1) There is a change which will force people to change the way they
configure ActiveSync accounts. Can/should we do something to allow
existing configs and/or existing configuration scripts to work?
2) How do we actually want it to work in the future (maybe an issue for
the next release)?