On Tue, 2013-08-06 at 08:45 +0300, Alberto Mardegan wrote:
On 08/05/2013 09:29 PM, Patrick Ohly wrote:
> 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.
Excellent, this is indeed the right way to do it.
> 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
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.
Hmm, okay. It just seems preposterous for a simple app to provide a
"google-contacts.service" or "google-carddav.service". This is not
Highlander where there can be only one (app using such a service). A
"google-syncevolution.service" would make more sense taking that into
account, but leads to a worse user experience.
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.
I agree, that would be good. At the moment, the code does not install
account template files, it merely ships them as examples. That could be
changed, of course, perhaps depending on a configure flag.
But I need to point out something that I already told Ken: I don't have
much time for this (business travel this week, vacation starting next
week). I can justify working on gSSO and Tizen integration, but for
everything else I depend on other developers providing patches.
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.