[Kde-pim] Akonadi-next and KAccounts

[Martin Klapetek]

On Thu, Sep 17, 2015 at 12:25 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> tl;dr ->
>
> * we'd need to port it to Windows; this might be easy. it might not be.
> * we'd still need to think of the dominant mobile ecosystems separately
> * the current code and repository layout is very much oriented to Plasma's
> needs, so some work would need to be done to make it more generally
> re-usable
> for Akonadi
>

I'm more than happy to repurpose the repo layout. It's just that besides
KTp and
Plasma Mobile there is nothing really using it yet, so it was enough for
those.

I'll try to clean things up a bit.


> > However, KAccounts is just a wrapper around libaccounts-qt (which itself
> is
> > a wrapper around libaccounts-glib), I have no data on how
> libaccounts-glib
> > itself is supported on different systems, but I would assume it works, so
>
> We'd need to confirm as we can't operate on assumptions for what is a hard
> requirement of akonadi. Doing some Internet searches turns up that it is
> focused on Linux (and POSIX systems), so we'd probably be the first to
> take it
> to that platform.
>

Understandably. I believe it would work fine or at least would be easy to
fix.
The libaccounts-glib basically just reads the .provider and .service files
from
a specified dir (I believe it can be overwritten by an env var) and then
stores
the configured account in a db in XDG_CONFIG_DIR, that's all there is to it.

The signond, the credentials daemon, is all Qt5 and should be very easy to
port it over; it uses dbus or normal socket for interprocess communications
iirc.


> > On Android and iOS I think it should use the native Accounts thingy it
> has,
> > I'm not sure/aware if libaccounts could be integrated with it and use it
> as
> > a backend though. I don't think that Android and iOS usecases ever came
> > up with libaccounts.
>
> So we'd use KAccounts on Linux/POSIX systems, port it to Windows or else
> use
> something more native there, and then use the native APIs on the mobile
> systems. Sounds like we'd require some sort abstraction, or else have a
> *lot*
> of duplicate code (not really an option). Given that KAccounts is very
> focused
> on UI interaction, I'm not really sure how we'd do that ...
>

KAccounts could be ported to Android (its Plasma Mobile version), but it
just
wouldn't feel right to have two account setups, maybe (the native one and
KAccounts one)? I dunno. I think the abstraction could/should go to
KAccounts
itself rather than Akonadi, eg. the GetCredentialsJob would retrieve the
creds
from the native system. But I have no idea if/how that is possible tbh,
never
really looked into it.

[snip]

> Those are actually a kded module plugins, which is KAccounts-only daemon
> [..]
> > daemons
> > doing things on those four events.
>
> Let me rephrase then ... why is the code for these things bundled with the
> daemon itself? (The KIO stuff is actually built right in .. not even a
> plugin..)
>

Well, wrt KTp and Plasma Mobile being the only users, it's basically a "why
not?"
I'll try to clean up the repo a bit nevertheless, currently it's not ideal.

[snip]

> I don't see that as a big problem though. This way
> > the plugins
> > have much more freedom and flexibility with their UIs.
>
> Generally, that's the opposite of what one wants for a system that should
> be
> as consistent as possible ...
>

Fwiw this assumption was broken from the beginning when signon-ui is
opening a browser window for oauth2 accounts where each service
(eg. Google, Facebook) has a different sized window because it needs
to fit the login webpage nicely, and then the KTp dialogs being a QWidget
dialogs (each again designed for different window size as each dialog
contains different widgets).

So while I see your point, we already cannot guarantee the consistency.
Unfortunately.

[snip]

What I was trying to ask was "can the appropriate KAccounts UI for a given
> sort of account be created and shown by an application?"
>

Yes, you'd require the logic from CreateAccount, but I guess that could be
wrapped somehow into the library, more below.


> As for entirely automated setup, there's not much point to using KAccounts
> if
> we have to go down to libaccounts at times as well; do you think fully-
> automated setup could be reasonably added to  / implemented in KAccounts?
>

Yeah. You'd just have to provide the default settings in the .service file.
And would have to somehow supply username/password/other credentials
where needed. I think it could work.

Cheers
-- 
Martin Klapetek | KDE Developer
_______________________________________________
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/