On 08/05/2013 09:29 PM, Patrick Ohly wrote:
As far as SyncEvolution is concerned, it doesn't care what the
mechanism is called. It just uses what is enabled for a service or
provider in the account.
Excellent, this is indeed the right way to do it.
The consensus is that SyncEvolution should not install its own
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
Because .service files (can) contain app-specific information, such as
the scopes and the client id/secret. Also, the authentication
method/mechanism could be app-specific.
You could reasonably claim that the .service files should be part of the
Ubuntu packaging, but then one could stretch your arguments a bit and
claim that the whole UOA plugin should be part of the packaging, then. I
guess it's a matter of convenience, that since you ship the code for
working with UOA, you also ship a .service file for it; at least as a
working example. Then indeed there's still the possibility that
packagers will choose to patch your .service file or use a different
one, but I think that it would be good for SyncEvolution to provide all
the necessary data so that after a "make install" in an Ubuntu
installation the user/developer gets the UOA integration somehow working.