[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:       Ian Wadham <iandw.au () gmail ! com>
Date:       2011-07-11 23:55:27
Message-ID: 8C72FD7A-3B14-4710-B64A-7D48F62AFD44 () gmail ! com
[Download RAW message or body]


On 11/07/2011, at 10:32 PM, Kevin Krammer wrote:

> On Monday, 2011-07-11, Ian Wadham wrote:
>> On 11/07/2011, at 2:00 PM, Kevin Krammer wrote:
>>> 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.
>> 
>> True.  Akonadi does not call for other *PIM* apps when you fire up KMail,
>> but it does call for Nepomuk (I know where that leads) and some things
>> called "resource agents" that I know nothing about.
> 
> True, it warns when Nepomuk is not available since, as a explained earlier, 
> the assumption is that most users want the associated functionality.
> This can most likely be improved by detecting the absence in applications and 
> disabling related functionality there.
> 
> As for resourcee agents, those are part of kdepim-runtime, used by Akonadi 
> "under the hood" for the actual data access.
> Decoulping, separation of concerns.
> 
I'm glad to know those principles are alive and well in KDE ... :-)  However the
KMail I have in Macports is not the forgiving animal you describe.  In the Akonadi
test report, there is only success or failure, no warning.

Prompted by Matthias Fuchs' query about versions, I did a bit of digging around.

The KMail 1 on my old Linux machine is KMail 1.12.4 with KDE 4.3.5, Qt 4.5.3
and OpenSuSE 11.2.  I used POP on my local service-provider's host and got
GMail to forward everything there.   That worked very nicely and I felt that my
archives were quite safe there (e.g. family stuff going back to the 90s).

The KMail I have on Macports and Macbook OS X is quite a different beast,
maybe even a chimera [1].  It says it is KMail 1.13.7 with KDE Development
Platform 4.6.4.  The Macbook desktop is OS X 10.6.8 (Snow Leopard) and the
Qt4-Mac is at version 4.7.3.  Macports seems to mix and match versions of
applications and libraries with cheerful abandon and maybe that is not a good
thing in the case of KMail.

I can find no trace of KMail 1.13.7 in SVN and git, but I think it must have been
a transitional version to KMail 2, around the times of PIM's move to git.  Was
it released or could it have somehow "escaped" into Macports?

Cheers, Ian W.

[1] Chimera: a mythical animal composed of parts of of several other animals.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]