[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi-next and KAccounts
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2015-09-17 7:40:50
Message-ID: 2688120.MLnWTTXixR () serenity
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

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?

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]

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)? Is it possible to start account creation without the use of a KCM? 

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)

Thanks!


[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! :)

-- 
Aaron J. Seigo
["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

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

[prev in list] [next in list] [prev in thread] [next in thread]