[Kde-pim] Akonadi-next and KAccounts

[Martin Klapetek]

On Thu, Sep 17, 2015 at 3:40 AM, Aaron J. Seigo <aseigo at kde.org> wrote:

> On Friday, September 11, 2015 09.37:12 Aleix Pol wrote:
> > It's mostly in kaccounts-integration (and upstream repositories).
>
> Thanks ..
>
> I have a few questions[1]
>
> What is the cross platform story? With -v, how does kaccounts work on:
>
>         Linux, but non-Plasma desktop environments[2]
>         MS Windows
>         MacOS X
>         Android
>         iOS
>

So KAccounts is built as a KCM, which thanks to frameworks /should/ allow
for
running elsewhere than Plasma (all that would be needed is kcmshell5 and
couple frameworks). It was never really tested on those platforms as there
was
really no demand for it.

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
in the
worst case, different UI(s) could be written on top. The current KCM could
even be made in such way that it installs an embeddable widget which could
be just shared by those other UIs.

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.


> Is GetCredentials the only way to get at an account? e.g. if a protocol
> does
> not use the "log in, get a token, use that token for later access" pattern,
> can KAccounts still be used? In the case of, say, an IMAP connection would
> the
> provider be expected to return the plain text password in the credentials
> map?
> Or is it possible to start a connection and pass the socket over?
>

The Accounts stack is just about storing the account settings and
credentials.
So it is expected to return the secret used to authenticate with that
particular
account (what the secret itself is is not important). KDE Telepathy uses it
to
store username-passwords pairs. Plugins for any kind of auth can be added,
upstream currently has only password and oauth2 afaik, so any kind of auth
is possible. Note that the credentials itself are stored in KWallet and
again it
takes plugins for that too, so even a custom store for the secrets could be
used.

With KAccounts, I guess we could add such feature as sockets opening
(KAccounts
retrieves the auth stuff internally, opens the socket and returns it;
something like
GetSocketJob).


> Why are there providers (e.g. owncloud, carddav, google-contacts-sync or
> kioservice) in the integration repository rather than in the providers
> repository? Why are all of those services other than owncloud in the daemon
> itself rather than implemented as a provider?[3]
>

Those are actually a kded module plugins, which is KAccounts-only daemon
that
monitors for new accounts, removed accounts and services being
enabled/disabled
and then acting upon those events. For example the owncloud plugin will set
up
contacts sync from owncloud into vcards (its main purpose is currently
Plasma
Mobile where the phonebook is vcards dir, doesn't have much use on desktop
as there is akonadi for that). So those are actually not providers but just
daemons
doing things on those four events.

The providers repository has only the definition files for providers and
services,
in other words it tells KAccounts what account it can create, what are the
auth
methods required and which UI plugin to load and which i18n catalog and
which
services the given account can have.

This repo separation is from historic reasons (2011 or so) when afiestas was
working on it. Maybe it doesn't make sense anymore and these should be
merged.


> Why is the config UI, as created in KAccountsUiPlugin expected to create a
> top-level dialog? Why is not a root widget (preferably sth QML) fetched and
> then the calling application create that dialog (or embed it somewhere in
> its
> UI)?


This is because the first user of KAccounts(5) was KDE Telepathy. KTp
already has
its config UIs in a self contained dialog. There was no feedback on that
from anyone
so it stayed like that. I don't see that as a big problem though. This way
the plugins
have much more freedom and flexibility with their UIs.


> Is it possible to start account creation without the use of a KCM?
>

Yes, have a look at the src/jobs/createaccount.cpp. All it needs is to know
which provider
(which account) it is creating. That job is currently tied a bit to the
KCM, but can
be fixed/improved.


> Can account creation for a specific type of service be initiated
> programatically? (versus the user taking action by, e.g., going into the
> control center and opening an accounts kcm, then selecting the desired
> service)
>

Yeah, you can just query libaccounts for a service type (eg. "IM"), see
which providers
contain that service, then just pick one and do what createaccount.cpp
does. No clicking
needed.

[1] to start with, in any case... once these more design-level questions are
> out of the way, there are other questions that are more
> "implementation-level"
> that I have ...
>
> [2] I assume the same way as in a Plasma env; but always good to confirm :)
>
> [3] If akonadi-next uses kaccounts, we'll end up having to ship and
> maintain
> that as well; if there are a lot of dependencies pulled in due to those
> providers/services, that complicates matters. If we ship a kaccounts
> package
> on MS Windows (e.g.), it would be nice to not be shipping a bunch of
> services/providers with it that are not in scope for akonadi (and all their
> dependencies). It would also be nice to allow the google contacts sync use
> akonadi for its work. But if akonadi-next depends on kaccounts and the
> google
> contacts sync is implemented in kaccounts ... circular dependencies! :)
>

I'm more than happy to split things in such way that you don't have to pull
3000 repos.
It's currently the way it is because it works for all interested parties,
but not set in stone.

The Google contacts sync is again meant for Plasma Mobile, where there is
no Akonadi
but I'm expecting that Akonadi-next will get used on the Mobile and that
the eventual
Google resource will make this google-sync obsolete.

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/