[Kde-pim] Akonadi-next and KAccounts

[Christian Mollekopf]

On Tue, Feb 23, 2016, at 04:09 PM, Martin Klapetek wrote:
> On Tue, Feb 23, 2016 at 9:50 AM, Christian Mollekopf
> <chrigi_1 at fastmail.fm>
> wrote:
> 
> > Hey,
> >
> > I've been pondering this for a while and here are my thoughts (they
> > might be ill informed in various ways, please correct me if I'm wrong):
> > * I don't think this is a cross-platform solution, starting from
> > libaccounts-glib going over dbus. It seems like a unix only solution to
> > me.
> >
> 
> It can also work through sockets iirc.
> 

That would help portability at least.

> 
> > * For credentials we'll probably want to integrate with whatever is
> > supported by the platform (native keyrings), and perhaps a fallback
> > solution that is portable (but I don't know what that would be yet).
> >
> 
> SignOnD, the part taking care of credentials, is extensible with platform
> plugins, ie. you can use native keyrings just fine.
> 

Clear. My point is more that I don't think sinond is what you'd want to
be running i.e. on android, we'd rather integrate directly with the
native keyring there. The same goes for windows and mac I guess.

> 
> > * The path to OAUTH is still a bit fuzzy, and libaccounts might help in
> > this scenario, but the server side is not yet there so it's not an
> > urgent target for us.
> > * libaccounts is all in all still a rather heavy dependency with various
> > components.
> 
> 
> > This puts libaccounts for me into the "enhanced platform integration"
> > department, and as such is of low priority for the time being.
> > I still think the idea of having an accounts based setup is a great one,
> > and something I definitely hope we can support at some point, but I
> > don't currently expect this to happen anytime soon.
> >
> 
> As long as it's possible to hook up kaccounts with akonadi/sink,
> I'm happy.

I haven't designed the mechanisms yet, but what I envision is
approximately:
* the sink resource requests credentials and those requests are provided
by either kube or some external system (like a libsso or a native
keyring).
* Kube provides a configuration system for all resources, but on
platforms that have different solutions available we'll use that
instead. On android we'd want to use the accounts setup, and in kde this
could be libaccounts.

So I think it will be possible to hook up kube/sink with kaccounts, but
it won't be our first target.

> 
> > I think our first step has to be an account setup within kube, with
> > credential storage somewhere (don't really know where that is yet),
> > because that's the only really portable solution that get's us started.
> >
> 
> So if the accounts-sso project would be fully portable, you would
> consider using it?
> 

I'm in any case open to pave the way for using it, but I'm not convinced
I can afford to rely on it as the only solution for credentials and
configuration. If the project is fully portable that certainly helps,
but I assume in some environments we'd just rather integrate directly
with the environment, unless libaccounts turns out to perfectly abstract
this integration for our needs.

> I would really like to finally get to the point where we have a single
> accounts setup place for the whole desktop rather than every app
> doing its own accounts management.

Understood. I'm open to work towards that goal, I just can't give you
any promises for what I'm doingtowards taht in any useful timeframe.

Cheers,
Christian
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/