[Kde-pim] configuration in akonadi-next

[Aaron J. Seigo]

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.

Also: if someone would like to tackle this part of akonadi-next, I'd be happy 
to collaborate/guide/mentor(-if-needed) ... if people think the above is a 
good idea but nobody steps up to take it on as a project, I may end up doing a 
requirements document for it and try to recruit a new developer via my blog 
with it.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141216/15d045ff/attachment.sig>
-------------- next part --------------
_______________________________________________
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/