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

List:       kde-devel
Subject:    Re: Design of PIM, etc. (was Build KMail only?)
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2011-07-11 4:00:12
Message-ID: 201107110600.19579.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday, 2011-07-11, Ian Wadham wrote:

> Surely, PIM could be designed around a shared data source (a relational
> database if you must) in such a way that the various applications can
> exist independently of each other, in a loosely bound form.

This is exactly how the new PIM applications are designed. Previous 
incarnations had dependencies on each other for certain tasks, e.g. 
KAddressBook and KOrganizer depended on KMail for access to certain type of 
groupware data and I think KMail vice versa depended on KOrganizer for 
handling events/invitations attached to email.

The new architecture allows each application to retain their functionality 
without depending on each other running or even being installed.
It's good to see that other people also find this decoupling to be a 
worthwhile goal.

> KMail could even survive without the
> data source.

Definitley. KMail might be overly assertive in that regard, normally PIM 
applications will indicate the unavailability of their data source by having a 
semi-transparent error overlay over their normal UI [1].

> I have used it without an address book for years and just
> relied on its memory for recently used email addresses.  And if the user
> wants Strigi and friends to index his/her emails, cannot KMail simply tell
> them where to find the emails by updating a shared file or database?

Actually KMail is not involved in this at all (remember decoupling?), a helper 
program is telling Nepomuk about emails and changes to email folders.
This helper is enabled by default since we assumed that quite some users of 
KMail might actually be using its search for email functionality and would 
like to continue to do so.

We probably don't have any UI yet for people who never search for emails and 
would want to have this deactivated, but that can probably be easily added in 
one of the next releases.

The immensely improved separation of concerns will allow a far greater 
tunability than any previous version could have ever achieved.
It's just that the main focus up until now has been to provide as much of the 
established functionality as possible.

Cheers,
Kevin

[1] you can check this for example with KAddressBook if you stop Akonadi while 
the application is already running.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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