On 08/03/2013 09:26 PM, Kanavin, Alexander wrote:
> * Installing accounts .provider and .service files directly into
> /usr/share/accounts is difficult. SyncEvolution doesn't know
> whether it needs to install for UOA or gSSO (they are slightly
> different) and installing "google.provider" may conflict with other
It would be good if it was possible to include several sets of
authentication settings in .service files for different SSO backends
(as opposed to just one set as is the case currently). I'm not a
libaccounts expert, but I think ag_account_service_get_auth_data()
could return the settings for the platform's 'default' sso (and
identify what it is), and there would be additional methods for
enumerating and retrieving auth settings that would include also
their SSO identifier.
It is possible to have many "method/mechanism" entries in the "auth"
section of .provider and .service files. So, if your oauth2 plugin needs
different parameters than ours, you can simply call it differently
(like, "goauth2"). The remaining problem is deciding which
authentication method to use; this is specified by the value of the
"auth/method" key, which can be stored in the accounts DB, in the
.service file or in the .provider file (in decreasing order of lookup
If we cannot eliminate the differences between UOA and Tizen, I'd
recommend that EDS treats them as different entities, and therefore
installs different .service files depending on the parameters passed to
the ./configure script. Then, ag_account_service_get_auth_data() will
return the correct values.
That said, I think that in both cases EDS should *not* install a
.provider file; it should just assume that one is already there.