架构之美——最终用户应用架构（二）
今天，我阅读的是《架构之美》的第十二章，这一章主要讲的是Akonadi框架，让我充分了解了Akonadi框架是什么？怎么用？
kde 4.1中的Akonadi是一个以mysql为存储管理的 KDE 4 存储接口。它分为两个部分，一个称之为 Akonadi服务器，一个是为用户程序提供的和Akonadi服务器打交道的库，Akonadi服务器是单独提供的程序，属于kde的支持部分的一个软件。用户库包含在kdepimlibs之中。Akonadi目前的主要应用是做为kde pim组件的一致的数据后端，如果Akonadi不工作，kde pim各组件按照原来的数据存储进行保存。
Akonadi框架的目标是提供一个访问和操作用户个人信息、关联的元数据以及这些数据之间关系的服务平台。它将从不同来源收集相关的信息，诸如从电子邮件和群件服务。Web和网格服务以及它所触及的本地应用程序和缓存中收集，并提供相应的访问机制。在某次会议中制定的第一份设计草案中，就提到了许多在该架构的后续迭代中仍然存在的关键点。最重要的决策之一就是不使用DBUS来传输实际的负载数据，这虽然是Akonadi中最显然可选的IPC机制。取而代之的是使用了一个名为IMAP的、能够处理成批传输的、独立的传输通道和协议。之所以选择它，主要考虑到它能够对数据传输过程进行控制，应此可以取消冗长的数据传输，这样数据管道就不会阻塞控制管道。基于IMAP的数据传输的负载要比通过IPC机制传输小得多，因为该协议就是面向快速和流式传送大量数据而设计的。而DBUS的传输性能正是放弃它的主要原因之一，在其文档中就已经明确地说明它不是针对这种应用场景设计的。这将可以复用现有的IMAP程序库，在实现该协议时可以减少很多工作。
Akonadi的一个核心观念是为系统中所有的PIM数据和相关的元数据建立一个集中的缓存。然而老框架假定对后端存储的访问通常是在线式的，二Akonadi引用了本地副本机制，这样当需要向用户显示数据时能够马上提供，例如它可以保留许多可能已经获得的数据，以便避免不必要的重新下载。应用程序希望能够直接从内存中获得当前所需显示的信息，而无需自己维护磁盘缓存。这样就需要使缓存是共享的和保持一致的，减少应用程序对内存的访问，并采用惰性加载等优化技术，不过这样做用户无法马上看到数据。由于缓存是一直可用的，虽然可能不完整，但在绝大多数情况下仍然是可离线使用的。这大大加强了基于不可靠、低带宽、高延迟网络时的健壮性。
Akonadi中还有一个基础性的视角，它在其第一次迭代的设计中就已经存在，那就是用来访问特定类型存储后端（如群件服务器）的组建将以单独的进程运行。这样做有好几个好处。与该服务器潜在的错误、缓慢或不可靠的通信都不会影响整个系统的可靠性。
通过阅读这一章，我突然发现世界上比你优秀的人比比皆是，所以我要送一句话给我自己：“压力不是有人比你努力，而是比你牛几倍的人依然在努力。”正如这两个公式所表达的那样：80% = 0%，100% = 100%。要么就不做，要么拼命做！