Chinaunix首页 | 论坛 | 博客
  • 博客访问: 92386493
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: LINUX

2008-05-27 16:28:18

由于生活工作上的繁忙,本栏目暂停了一段时间,现在我回来重新为大家介绍KDE4背后的技术。本周的主题是,这是一个在KDE4.0中将得到广泛使用的信息提取子系统。KDE原本就有从各种类型的文件中提取信息的功能,并可以将它们用于一系列程序环境中,例如属性对话框。Strigi能为这些功能带来全方位的提升。下面是详细内容...

Strigi是一个比KDE层次更低的函数库,它用C++编写,其设计目的是为其它程序提供一系列常规命令以从选定的文件中得到更多的信息。除了使用了KDE的SVN库之外,它与KDE并没有什么关系。它也拥有搜索的能力,但这并不是我这篇文章的焦点。

Strigi库可用于从文件中得到信息,例如一个图片的面积,一个音频文件的播放长度,内嵌的草图,日志的行数,源代码的许可信息或者可以在一个文本文件中寻找特定字符串。Strigi还有其它优点,即它可以无缝地用于搜索压缩归档文件。事实上,它同时提供了一些有用的程序工具,叫做deepgrep和deepfind。这些有用的命令行程序允许你在二进制格式的文件中检索,其用法就像是在普通文本文件中进行grep或find检索一样轻松。KDE继承了相同的库,于是我们可以利用这种独特的好处从深埋在如.tgz这样的二进制文件中取得信息了。经Strigi增强后的kio_jsteams框架将归档文件看作是本地文件夹,例如它可以让你访问/home/user/tarball.tar.gz/icons/。当你使用KDE软件调用kio_jstreams时,它可以工作的很好,但目前你使用其它类型的软件时就会出问题。例如,当你使用Konqueror浏览,点击一个归档包中的文件,然后你希望用Gimp来打开它的话,将这个文件传递给Gimp时会造成Gimp的崩溃。正因如此,此类操作目前还只是kio_slave的试验级特性,只有到这个问题得到解决才会推广到所有程序(另一个问题是它会将tgz或odp文件既看作是一个文件,也看作是一个目录)。

Jos提到:“这个xmlindexer程序可以高效地从文件中提取信息。因为它可以输出为xml,它可以轻易地被其它程序所利用。其它搜索程序如Beagle和Tracker也可以从xmlindexer的工作中得到巨大的好处。”xmlindexer程序是二进制的,所有程序可以轻松地在外部调用它,而不需要链接到Qt或是使用C++。也就是说,有很多方式可以直接使用Strigi库……

过去KDE库拥有很多从文件中提取信息的方法(如通过KFileMetaInfo提取元数据),但在很多情况下它们不是运行很慢就是功能上有限制。而使用了Strigi之后,当我们从PNG文件中提取数据时会发现速度有飞跃提升。我不太清楚其它的速度测试,但令我印象深刻的是它在检索数据时比当前存在的方法都要快得多。

在KDE中还真的无法用截图来显示Strigi的工作情况,因为它只是一个库。但也不能说它的作用是不可见的,如文件属性对话框等程序已经使用Strigi作为后端来提取数据,而这项工作以前是由KFileMetaInfo完成的。另外Strigi计划被用于在文件浏览器中显示草图以及其它元数据(在某些方面已经实现了),并且初步的结果显示其速度有了非常明显的改善。但到目前为止,它还不能为最终用户带来直观的KDE体验,至少还不能给大家带来视觉上的体验。然而更多KDE的子系统开始注意Strigi,我们很快就会看到Strigi为我们带来更多独特而有用的特性了。

例如:Strigi项目最大的捐赠者是。Jos称“Nepomuk是一个大型的欧洲调查项目,它旨在增强计算机程序的智能化和相互连接。是Nepomuk的标准及想法的KDE实现。我与Nepomuk的人们一起工作,特别是和Nepomuk-KDE的Sebastian Trueg的合作让我们的工作更加顺利。目前Sebastian正在为Strigi编写一个附加的索引程序,它可以更好地用于检索语义学数据。”这个项目使用了大量的元数据和其它文件内容(如IRC的聊天记录文本)以提供一个简单易用的桌面搜索系统。NEPOMUK在它最终成型之前还将经历一次改名。

由于Strigi实现的是对数据深层次地发掘,因此如Dolphin/Konqueror,文件属性对话框或NEPOMUK等程序中将会显示其成果。目前的工作主要集中在将现有的KFilePlugins机制转向使用新的Strigi后端。想要了解该工作的进展,请访问KDE wiki的。

想要了解Strigi的更多信息,请访问或加入irc.kde.org的#strigi频道。

阅读(259) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~