[Kde-pim] configuration in akonadi-next

[Christian Mollekopf]

On Tuesday 16 December 2014 20.30:47 Aaron J. Seigo wrote:
> Hi,
> 
> Working through design concepts and code a bit more with Christian today, I
> started thinking about configuration. There are two parts to this: storage
> and user interface.
> 
> Currently in Kontact there is a standard UI for configuring each component
> (KMail, KOrganizer, ....). To make this more usable, there is the accounts
> wizard which guides the user through an easy setup of even complex
> configurations.
> 
> In future, I would like to see configuration go entirely the way of the
> account setup wizard: the user sets up resources, not individual
> SMTP/POP/etc accounts. Yes, the user will be able to set up an SMTP server
> on its own, but this will be done as a resource, no different from the
> process they configure a Kolab account with.
> 
> This will vastly, vastly simplify the user experience IMHO and also put
> configuration right where it belongs: in the resources.
> 
> In the Akonadi Next design, clients load Resource plugins to provide a
> facade for data in storage that gives the client domain objects. Since the
> client already has this plugin available, it makes sense to also add
> configuration here as well imho.
> 
> The end result should be that the account setup wizard disappears in its
> current form with the various setup UIs it currently has going straight into
> Resource plugins. Configuration would no longer be "per client" as it
> currently is, which is really a hold-over from the pre-Kontact days, but
> per- resource. Configuring your resources would be done from a single,
> unified dialog focused on, well, resources. Clients could filter the shown
> resources based on the resource types it is interested in (so KMail
> wouldn't need to show e.g. newsfeeds ;) ...
> 
> Then there is the question of how these are stored on disk. IMHO it would
> make the most sense to keep each resource's configuration together, even if
> that resource provides email, calendar, notes, contacts, stmp, ...,  as
> Kolab does.
> 
> Again, all of this would remain encapsulated in the Resources themselves.
> 
> Finally, a way to migrate existing configuration to whatever the new looks
> like will be required.
> 
> Ok, so that's my thinking on the matter and the akonadi-next design is well
> suited to pull this off. But perhaps I'm smoking crack here. :)
> 
> Input and ideas from the sages of KDE PIM are most welcome.
> 

I fully agree that resources can provide their configuration UI as part of the 
plugin, so we get a nice in-process ui that the clients can embed. I'm not 
sure though it makes sense to move everything there.

What we're aiming for with KAccounts AFAIK, is that we think more in terms of 
services/accounts and not individual protocols. I think this is very much the 
right thing to do.

Taking kolab as an example, we typically have a setup that consists of:
* imap connection + kolab resource
* ldap connection for the addressbook and potentially more in the future
* smtp connection to send email and iTip invitations
* filesync to have something additional that is not yet there but will be 
eventually
* and at least one identity that is associated with the account

All of this essentially requires a single url to the server + a set of 
credentials and the rest can ideally configure itself. I think everyone agrees 
that we're aiming for the user only having to provide exactly that.

As it currently stands, I don't see ldap, smtp and filesync as part of what 
the akonadi resource should be dealing with, and thus I don't think the 
resource configuration is the answer to this problem (perhaps it could be but 
I don't know yet how).

We already do solve the setup process somewhat with kaccounts/accountwizard, 
but we end up with a scattered mess of configurations as aaron already pointed 
out. Currently you have to configure ldap in kaddressbook for kmail addressee 
autocompletion to work, and you have to setup smtp in kmail for korganizer to 
be able to send iTip invitations. If you ask me, that sucks.

I therefore fully agree that we need a more central place for configuration.
Here are a couple of requirements from my side:
* provide service + credentials and your done setup
* to adjust something in the settings you can go to the same place (in the 
UI), and not find the option in one of the applications.
* a service should have the possibility to provide + sync some parts of the 
configuration, such as available identities.

Here's what I think could work:
* KAccounts was created for this exactly, and is therefore probably what we 
should use.
* *all* connection related configuration should move in there:
** imap/pop3/ldap/smtp/dav/urls for filesync/....
* It should absolutely be possible to setup a single smtp connection (as 
laurent mentioned). If you use a kolab service everything will be configured 
at once, but if you want to setup smtp and imap individually you just pick the 
smtp and imap services instead of kolab.
* Since the services will provide the configuration UI of the resources, 
they'll just load it from the resource plugins.
* We replace all relevant configuration in the applications with 
configurations provided by the services in the form of loadable plugins.
** kmail would show all mail related services in its config
** korganizer would show groupware servers and ical sources in its config

This way we can get IMO the best experience possible where you can manage your 
services/accounts centrally while still allowing to access the relevant 
configs from the individual applications.

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/