那些KDE中的技术(二)Akonadi

csslayer | 2010/12/12

这同样也是一个备受争议的玩意。尤其是它还和Nepomuk搅到一起,让很多人更加不满意。

先说说它是个什么东西。简单说来就是一个个人信息管理框架,名称象征迦南神话中代表公正的预言女神。它的目标是实现一个跨桌面的个人信息管理的框架。可以参见下图:

什么,你没有看错,计划里面是有Gnome的,虽然我并不清楚Gnome方面是完全没有动作呢还是怎么样。这个东西的目的就是将这些个人信息管理的数据和上层的应用分开,比如邮件管理,没有必要每个邮件程序都去搞一套POP3或者IMAP接受,只要从一个地方获得数据就好。甚至考虑到这个数据源可能不在你的电脑上,那么无论是你在公司的Gnome,抑或是笔记本上的KDE(举例而已),都可以享受到同样的数据服务。

同时在Web Application如此泛滥的年代,它同时也可以起到整合各个数据源的功能,比如日历,你可以使用远程文件,也可以使用本地文件,以及其他各个日历服务。甚至作为微博客的数据端(我看到现在已经支持这个功能了,但还没有测试过)。

他获得争议主要有以下几大原因,使用Nepomuk,后台进程,使用Mysql,以及早期bug繁多(这也是没办法)

早期来说这个实现还并不成熟(KDE 4.4时期),现在(KDE 4.6)已经变得更加成熟了一些。

为什么使用MySQL,这点的理由其实和Amarok的开发者很类似(原文翻译),对于很多人喜欢的SQLite,他们的理由是无法支持高并发的访问。为什么没有和Amarok一样使用MySQL的嵌入模式,这是因为它无法支持InnoDB(MySQL的一个存储引擎,支持事务)。当然,和Amarok略有不同的一点是他还支持PostgreSQL作为存储引擎。

为什么需要Nepomuk?[1][5]

他们需要对虚拟文件夹进行快速的搜索和管理,Kmail自己的实现对于大量的文件来说已经不够了,而Nepomuk正好满足了他们的需求。同时,Nepomuk也可以提供有效的元数据查询服务。

关于资源的占用方面,我想大概这就是一个Trade off的问题,尤其是在硬件条件已经发展的情况下,不过话说回来,我运行很久KDE 4.6之后,同时Kmail也开关过几次。把所有程序都关闭(firefox之类)只剩桌面之后占用资源也不算很多。考虑到我的笔记本是4年前的纯种联想笔记本的话,其实我觉得没什么大不了的。

对于希望使用轻量级桌面的人来说,我觉得某种程度上需要做出取舍,自然,有Xfce,LXDE这样优秀的轻量级桌面供你使用,同样的如果你选择了KDE的话,那么你可能还是期望着更好的桌面体验,不是吗?(除非是它占用了不该占用的资源,那么你应该去汇报bug,:) )

对于用户来说,可以利用Akonadi达成平滑的跨桌面的个人信息管理体验。对于开发者来说,则可以利用各种各样的现有资源实现自己的应用。我个人喜欢KDE的一个原因就是我总是能在他上面体会到各种各样的新鲜的技术。

从目前Akonadi已经具有的功能和KDE现有的应用来说,我能想到很多有趣的玩法。KDE总体来说给我感觉是非常Web友好的,从Get New Stuff和openDesktop的集成来看,从Plasma对Google Gadget的支持来看,从Akonadi的后端也有很多Web资源(网络下载ical文件,日历支持blog,微博后端等)来看,我觉得在Web App发展到极致之前(比如Chrome OS真的能以不变应万变,虽然这在什么时候能够实现也未可知),KDE肯定是一个很好的选择,不过到那时KDE会发展成什么样呢(其实我很期待KDE占领移动平台,从我第一次看到手机上跑起来的Plasma就开始期待了) ?同样也是异常值得期待的。

资料来源:

1 Akonadi, Nepomuk and Strigi explained

2 KDE PIM – Akonadi

3 Akonadi – KDE Userbase

4 Akonadi – KDE Techbase

5 通向KDE4之路(十七):KDE PIM库和相关技术

Tags: , ,

5 FEEDBACKS

  1. pingz

    我一直都搞不明白为什么现在什么程序都需要一个“数据库”,其实一般的文本文件当数据库未必不能满足需要,特别是现在的文件系统和硬件都这么好的情况下。像火狐,一个书签都要搞个数据库,这种东西真的会引起性能问题吗?历史记录也是一样,就用户1s产生一条历史记录,一天也不过86,400条,一年下来才三千多万条。对于现代的计算机,处理这种量级的纯文本会是问题吗?我现在处理的文本比这要大的多,也没见慢到哪里去。

    对99%的用户,这类数据库除了增加软件的大小,基本上没有任何意义,甚至还会引导性能上的问题。当然,也许只是因为我对数据库比较白痴。也许这种东西对加快开发进度有意义。

  2. csslayer

    @pingz 数据库有很多意义。某种意义上讲我也是研究数据库的(研究僧一个),所以我说下我的理解。文本文件难以管理,这体现在很多方面,比如无法支持并发(多线程就很困难),没有方便的查询接口,没有索引管理。很多情况的操作难以处理,比如说历史记录你删除一条,那么会怎么样?按文本文件把后续内容前移?这有很大问题,比如你按照磁盘页面组织,可以,可这也就是传统数据库的技术。数据按照什么顺序组织?对于书签可能时间序是一个很好的选择,对于其他的内容呢?如果你把这一切的一切的各种细节都处理好了,到头来你发现你不如用一个数据库。你写的代码可能有bug,而且很多。那些数据库起码有各种人已经实际使用可以保证可靠性。各种方面上来说我不排除你的文本文件也可以使用各种技术来解决问题,可这一切的一切早都好好的实现在数据库里面了,重复制造轮子没啥意义的。

    退一步说,纯文本和数据库在你看来有什么区别呢?这个文件如果不需要用户去读取,又何必存成纯文本?退一步说,假设有一个数据库,数据文件只使用任何可以输出的字符并且组织成可读形式,这在你的概念里和纯文本差不多,那和纯文本又有什么两样?(虽然存成文本是完全没有必要的,如果你觉得真的会有人去读它的话,二进制明显更加紧凑)

    你处理文本当然没问题,对大批量文本处理来说,读取是线性扫描一次过去的,而不是需要随机读取。我对你举例的随机读取性能难以想象。firefox的历史记录管理的界面,各种排序方法,按站点,按时间,瞬间就能完成,只靠你的文本处理就能完成吗?…很成问题啊。

  3. pingz

    @csslayer 我只是觉得这类个人应用还没有到非要用到数据库的程度。我并不是说数据库没有用。我只是觉得数据库技术被滥用了。

    回到历史记录的问题。事实上,我从来没有用firefox来回溯过一周以上的网站浏览记录。如果我要去了解我一年以前看什么,我会去找Google的web history。再久,只可能是我专门做过记录才成。我不太相信有人拥有数万条历史记录。大家确实都对自己浏览网站的历史记录进行清理和分析。但是没有人会以分析清理自己的历史记录为生。对历史记录进行并发访问,随时删除,更是我想都想不出来的应用。至于瞬间完成排序,我从来都只用按时间排序,但我不觉得如果用文本,在性能上会有多少拖累,有多少人的历史记录会超过十万条?更不要说依现在的网络技术,很多你在网上的操作是不可能简单地用浏览器带的历史记录就查出来的。

    还有amarok的曲目库,自己花了大力气整理出来,却不能方便地在各播放器间通用,也很让人很头痛。

    相比firefox和amarok,Akonadi运用数据库技术的方式要灵活的多。但是由于其目标是实现一个跨桌面的个人信息管理的框架,我觉得Akonadi还是过于依赖数据库技术。

    另外,关联型数据库设计未必会比组织好目录结构来的简单。组织数据的工作总是需要程序员干预的,不可能用了数据库就不需要组织数据。最后,我举的例子恰恰没有多少随机读取上的性能要求。

    重点是简单的应用,不应该采取过于复杂的解决方案。

  4. csslayer

    @pingz Amarok的曲目库……你觉得哪个播放器的曲目库可以通用?相反我觉得Amarok这样更好,它可以使用公共的MySQL服务器,换句话说其实Amarok的库更加有希望可以四处使用。(另外其实一个更简单的办法是用Amarok和lastfm集成?)

    firefox的话,我想很多人会习惯于在地址栏内直接输入东西,至于那个历史是一周前还是昨天的其实并没人在乎不是吗?足够多的历史才能告诉程序你足够多的信息。比如我现在在我的地址栏输入dm,就会自动把我常去的一个网站列在前面,而不是其他我不常去的包含dm的网站。如果每次都不得不扫描完整历史,firefox的性能得成什么样子。你可以按照你说的方法尝试一下,不过我不看好。

    你举的例子是指处理文本?那当然不用。但是桌面应用才是随机读取啊。没有数据库的话,我难以想象我根据歌曲当中任意标签查询能够获得多好的性能。再说Amarok也有调整目录的接口…

    相反我觉得这就是最简单的解决方案,不会比你的文本还复杂,这个复杂与否其实是对于程序员来说的,用户其实不care。

  5. 虽然我没啥研究,不过我支持CS Slayer仁兄的观点。 我以为数据库的“复用”是一个很重要的方面。我记得曾经和一个GIF Maker讨论过一个问题,他认为现在的GIF无法满足他的要求,视频又限制太多,于是他设想了一种“支持播放控制、有高压缩比率的动态图片格式”。然而你会发现当你做出自己想要的一切功能的时候(例如有编码就要有解码,要有分离器、同步器等等),它在本质上就已经成了一个视频。如果说我们用一个所谓的“文本”,再加上一些复杂的代码完成我想要的所有的功能,再解决访问的问题,最后我们会发现它就是一个数据库。不论它是一个什么样的形式(例如人类是否能读懂),其最终的目的、理念甚至方法都是一样的。SQL是规范的标准,各种数据库的实现是成熟并且在一定程度上通用的。如果我是一个开发者,我肯定不会愿意再花时间在这些问题上。

    另外还有个共享的通用性问题……Amarok暂时先不提,Akonadi共享方面的设计是考虑到Gnome的。之所以现在显得不那么通用,是因为还没有确立一个“事实上的标准”。而这个标准最终会由谁来确立?我想照目前的进展来说应该不会是Gnome。现在KDE迈出了第一步,如果KDE成功了,其他桌面环境可能会向它看齐。这时候如果我不使用数据库,其他桌面环境的开发者就要学习KDE所开发出来的一套自创的(并且可能是比起SQL来说拙劣许多的)方法,这似乎不是降低而是增加了成本。

    实际上我一直承认KDE4的理念似乎过于超前,这也是KDE4一出世就顶着这么大压力的原因。但总有一天这些技术会成为实际的应用,那么如何在一开始就让每一个部件尽量的规范化(而不是到日后再大费周章地修改),大概一切都首先应该基于可靠的技术。

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).