[Kde-pim] configuration in akonadi-next

[laurent Montel]

Le Tuesday 16 December 2014 20:30:47 Aaron J. Seigo a écrit :
> 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.

It's not the case with actual akonadi ?
We have config in each resource no ?

> 
> 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.

When we configure an kolab it can be used by korganizer/knotes or kmail and we 
can configure it in each apps.
We don't configure in kmail, and after in korganizer etc.

We configure just once.

> 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 ;) ...

It's the case. In kmail we show just pop3/imap/kolab we don't see newsfeed or 
ical etc.

> 
> 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.

There is just kolab with provides kolab support + imap.
But imap resource provide just imap same for pop3 same for maildir same...

I don't understand what is the improvment here.

> 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.

-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141217/aacd92c3/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/