On Mon, 2013-08-05 at 15:52 +0300, Alexander Kanavin wrote:
On 08/05/2013 03:30 PM, Alberto Mardegan wrote:
> I don't think it would be too hard. We just have to discuss any upcoming
> changes on the mailing list, before implementing them.
You can find the documentation for the glib plugin here, so you can see
what else has changed:
As far as SyncEvolution is concerned, it doesn't care what the method or
mechanism is called. It just uses what is enabled for a service or
provider in the account.
The consensus is that SyncEvolution should not install its own .provider
or .service files, right? In that case it is not necessary to make
the .provider and/or .service files compatible with both gSSO and UOA.
This is something that the system integrator or users must get right.
EDS is not installing the google.provider on Ubuntu. Why is it
installing the .service files for it? That part does not make sense to
SyncEvolution only cares about the methods that it needs to call
signon_identity_create_session) and a few well-known key names
("UiPolicy", "ForceTokenRefresh", "AccessToken").
Would it be possible on a common API and then also name the shared
library implementing that API the same, like libsignon? Then
SyncEvolution could compile and link against either gSSO or UOA while
still being compatible with the other.
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.