KDE有大量的子项目已蓬勃发展为庞大的项目，其中如KOffice、KDE-Edu等都获得了开源世界的广泛好评，在这个时候，KDE PIM项目也已悄无声息地获得了业界认可，成为了一套适用的企业套件。今天我们介绍的特性是强大的项目的类库及其从KDE 3.5.x以来发生的变化，KDE PIM项目是KDE中诸多最为成功和稳定的组件中的一个。有关细节，请继续阅读。
KDE PIM（个人信息管理）团队已经稳定地完成了他们的主要目标。其间取得的成果是，KDE PIM不像其它那些进入到KDE 4应用程序中的新技术那样频繁变化，事实上，很多KDE 4 PIM应用程序最初看起来都是由KDE 3.x中对应的程序直接移植过来的。现在，主要焦点已经转换到了将会在未来得到验证的技术，因为现在是打破旧的API，引入新的API的时机，这样的机会并不多见。因此，我们已经开发了大量的新库，并且重写了旧库。
Akonadi
Akonadi是KDE中新的存储后端，名称象征迦南神话中代表公正的预言女神。它并不是真正的后端，只是一个通用的后端API，它可以有任意多个真正的存储解决方案实现，从纯文件到复杂的群件服务器。它支持缓存，所以离线模式是隐含可用的，而不用考虑数据实际上如何存储和获取。
它被认为是KDE中现存的资源框架的替代，但是它还可以扩充KDE 3.x中不可用的数据类型。例如，Akonadi框架对于电子邮件、联系人和日程表正如旧的框架那样非常有用，但是它还可以扩展大量其它有用的类型。Akonadi的杰出开发人员，Volker Krause，对于即时消息（IM）日志的支持建议是非常有用的，因为这样就可以使从基于浏览器的GoogleTalk中获取日志和从您的硬盘中存储的日志中查询一样容易。当然，它会被缓存，用户不用每次都直接访问GoogleMail就可以进行查询。
另外，Volker写到“Akonadi使用了一套完全和语言以及工具包无关的接口，它基于D-Bus并且是一种类IMAP的协议，这使得它可以被那些没有连接到KDE/Qt库的非KDE软件使用。”这也就意味着您可以编写利用Akonadi优势的轻量级程序，而不用和整套KDE以及Qt库链接。这个D-Bus控制还可以用来访问Akonadi中存储的数据，例如编写自动执行的脚本或者类似任务。
这也就是说，Akonadi的一些部分和Qt以及KDE集成地非常好，尤其对于那些想要处理Akonadi中存储数据的应用程序的复制/粘贴和拖放等操作非常智能。例如，如果您拖动一个联系人的名称到一个文本文件中，您可以得到他们的姓名，因为这是文本文件唯一能够理解的格式。如果您把它拖到一个日程表中，这个日常表可以很容易地识别它并且把它接收为一个联系人的释放，并且继续询问您是否要为这个联系人安排一个约会等等。这些库支持这个水平的集成，但是距离这些程序获得它完全的优势，还需要一段时间。
对于存储，Akonadi仅仅受限于已经被编写好的插件。默认情况下绝大部分数据都会被存储在文件中，现在这部分已经基本完成，但是像处理使用一种SQL数据库或者类似的后端数据库之间的关系还没有完成。在以前，KMail、KNode以及其它，每一种对于数据的关系都不得不有它们自己的实现，并且通常使用的是应用程序特定的二进制格式。这些数据现在不能够很容易地共享。另外，Akonadi为如变化通知这样的事项提供了“永久唯一标识符”，这是为了能够实现有效的元数据查询，例如NEPOMUK-KDE集成中会提供这一功能。Akonadi本身没有提供元数据索引，但是它是使用这样一种方式编写的，例如可以把现存系统和激活的任意存储后端连接起来。
由于Akonadi是“类型中立的”，其它库不得不根据它们所支持的每种类型而实现。在一些情况下，这些库必须根据现存的KDE 3.x的库重写（例如联系人），并且在其它的情况下，需要一些伪装才能使现存的库正常工作（例如KCal、KMIME等等）。
这里，我将再一次强调虽然这个库会和KDE 4.0一起发布，但是KDE PIM应用程序将不需要和这些新功能完全集成。在这一点上，依赖底层工作并且确保API是完整的是简单的，这样就不会阻碍未来的KDE 4.x版本。我认为Akonadi的开发是KDE PIM整个循环中发生的最大变化，并且也许对于KDE PIM的未来长期发展是相当重要的。
Khalkhi
Khalkhi是设计用来作为KDE 4中新的联系人框架的，这个词来自乔治亚语中“人们”这个单词（它的发音目前还无法使用英语描述，但是Friedrich已经在中作出了尝试，在那里也有些有关这个技术的相当不错的介绍。）它所包含的大量新特性是现存的KABC所不能做到的，例如：
- 它有一个组的概念，就是人和人之间的关系。人可以属于组。组可以属于其它组。NEPOMUK可以发现人和人之间的关系，这样就可以为它的搜索和索引提供帮助。
- 在组或人之间共享属性。例如，如果您对许多人定义了一个共享的邮件地址，那么您可以一次为这些人更改此联系人信息。
- 基于插件的属性类型。您不会再被局限在KABC的代码所限定的联系人信息，例如电子邮件地址等。您可以通过添加新的插件简单地添加新联系人信息类型。例如，添加一个字段，它对应着在线网站上地用户帐号（例如Flickr照片共享，或者Last.fm音乐资料等），然后它对于可以被所有使用联系人的应用程序自动开放。
- 增量更新。在KABC中，在任何发生变化的时候，程序都不得不重新载入所有联系人列表，如果对于庞大的联系人列表，这样非常没有效率。Khalkhi可以以增量的形式处理这些变化，而不用重新载入。
Khalkhi就是在其它库后面隐藏的一个小小的集成，并且也许在KDE 4.1发布之前才会让大家见到。如果您对于这一技术感兴趣，并且想帮我们一把，您可以直接联系Friedrich Kossebau，或者直接在IRC的#kontact频道上联系。
KitchenSync
名称没有改变，尽管它是一个全新的项目。正如Cornelius Schumacher所说，“它只是被叫做KitchenSync。它只是和KDE 3的KitchenSync名字一样，并没有共享其它任何东西。”
KitchenSync是KDE中用于同步的库和GUI，它实现了从大量不同的PDA以及类似设备中获得数据的方法。KitchenSync现在是基于OpenSync基础构造之上的一个框架，界面完全来自于旧版本程序的移植。插件应该会更加稳定并且现在由它们所在的OpenSync项目组维护。这样将会使KDE和其它项目受益，受益的方式和面向扫描仪的SANE抽象库是同样的方式。
KDE PIM开发人员Tobias Koenig说“现在因为插件来自于OpenSync项目，所以我们将会拥有更加通用，测试更全面的一套插件。唯一需要移植到Akonadi的插件是OpenSync kdepim-sync插件。不过这个很快就会被完成”。OpenSync是和GUI无关的，目的是简单地处理和设备之间的数据通讯，这也就是说我们仍然需要对话框来配置连接。幸运的是，他说：“为了使实现更加简单，一个当前（Google代码之夏）项目就是有关根据插件配置设置创建抽象描述（XSD）的，因此这些配置对话框可以被自动创建。”
KitchenSync已经为KDE 4提供了相当好的功能，但还有一点没有完成，在4.0发布的之前会完成的。
邮件传输
这是KDE 4.0中的一个新库。它本质上是一个集成库，用来共享电子邮件设置，相对于KDE 3.x，这是一种非常高明的方式。在KDE 3.x中，您不得不在每一个应用程序中分别地设定您的邮件帐号。Volker Krause这样描述它：“一个专注于邮件配置和发送的小型库。真正有意思的是它被KMail、KNode和Mailody使用，并且允许他们共享相同的设置（包括如果你在一个应用中修改了他们，其它的也会即时更新）。目前正在计划对身份(identity)作出与之类似的变化（也许在KDE 4.0的时候还未完成）。”
这个库将使电子邮件服务集成到其它应用程序变得更加容易，因为我们不需要每一个应用程序都知道电子邮件是如何被发送的。它将会出现在KDE 4.0中已经存在的KDE应用程序中，但对于第三方应用程序也会有强大的促力。
联合（
Syndication）
新库开发人员正在激烈讨论有关处理大量的新的联合格式的问题，并且提供应用程序可使用新种子的一个新API。现在，它已经支持常用的格式，其中包括Atom、RSS2和RDF。以后添加新的格式将不会太难，并且正在使用联合的程序可以自动地感知它们。很多PIM的开发人员认为联合应该是添加到KDE 4.0的kdepimlibs中最令人兴奋的特性。
扫尾
还有很多新的工作进入到KDE 4.x的PIM库中，其中一些也许不能及时加入4.0。在KDE 4.0发布的时候，很多KDE PIM应用程序尚无法更新到新库，但它们还会继续使用3.x库的移植版本。正如我前面所说的，KDE PIM的一个主要目标就是稳定，并且在4.0发布中继续使用旧的库，您可以确保您至少有一个功能和3.x应用相同的可用PIM环境。不过，我们当然期待着将在KDE 4.0之后面世的KDE PIM将带来的全新的令人兴奋的内容。另外，KDE 4.0发布已经越来越近，期待一些专门讲述这些PIM应用程序的文章。
最后，我再给大家说几句。本篇将会是由DOT新闻发布的通向KDE 4之路的最后一篇文章，因为我正在迁移到一个新的领域，在那里，我将把KDE推向到科技世界中更加广阔的领域。我还不能透露所有的具体细节，但是我保证这些文章仍会在DOT中保留。这很好，因为DOT是一个完全开放的，不会修改评注的论坛，并且很多文章都曾酝酿了大量对开发人员有实际意义的反馈。下一篇文章将会是Krita或者Kate（还没有决定先来哪一个）。
