On Wed, 2019-01-23 at 10:27 -0500, Matthias Clasen wrote: > > > On Wed, Jan 23, 2019 at 10:03 AM Bastien Nocera <had...@hadess.net> > wrote: > > On Wed, 2019-01-23 at 14:33 +0000, Allan Day wrote: > > > Bastien Nocera <had...@hadess.net> wrote: > > > <snip> > > > > Flip it on its head and please suggest why, nowadays, any > > > > application > > > > developer, whether for a GNOME application or a third-party, > > would > > > > spend time integrating services into gnome-online-accounts, or > > > > using > > > > gnome-online-accounts for functionality that's somewhat core to > > the > > > > application experience, when the rug can be pulled from under > > your > > > > app > > > > at any point? > > > > > > That's not what's happening here. Until very recently, Debarshi > > was > > > the Documents maintainer, and he's obviously been fully involved. > > > > It is what is happening in GNOME Online Accounts in general. Pocket > > is > > disabled in Fedora 29, and there's a good chance that the mail > > configuration bits will be disabled in Fedora 30. > > > > I don't know whether those changes will also be done upstream, but > > the > > result will be the same, it won't be possible for applications > > shipped > > through Flatpak to know that certain configuration options will be > > available in GNOME Online Accounts. > > > > I believe in the larger picture, this is a logical consequence of > taking the boundary between desktop and apps seriously.
Right, and a functional regression for applications (core or not) that relied on GNOME Online Accounts to enumerate services the user had setup and authenticate with them. As Emmanuele mentioned, the problem isn't so much that services will disappear from under the applications (but it's a problem nonetheless), it's that there was no communication explaining that applications shouldn't have relied on GNOME Online Accounts in the first place, as the functionality could disappear for reasons not caused by those services, or applications. > It is just not right to give all 3rd party apps that show up in a > flatpak access to the GNOME api keys and identity. > They need to use their own keys. Offering a centralized service for > storing such keys, as Emmanuele suggests, > might still be useful. With a per-app key usage, you end up losing the single sign-on, for example if you had 2 separate contacts applications, you'd need to login twice to authorise 2 contacts applications separately. The only thing you'd gain from this is that the application wouldn't need to reimplement the authentication. It would greatly reduce GNOME Online Account's "system" integration, turning it into a library to help with authentication. My own take away from this thread is that, as an application developer, I shouldn't count on GNOME Online Accounts at all for my app's core experience. Is that a fair assessment? _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
