首先我觉得应该先谈谈这个Gds的发展过程.目前GDS 已经发展到2.0 beta版本.在google的论坛上,GDS 的 sdk开发已经有一年左右时间了.但直到现在,开发项目基本上只基于国外.目前国内基本上没有什么相关项目对GDS的应用进行开发.对于这点我一直很困惑.难道是国内开发者认为这个东西真的不成?
我今天又在网上搜索了一下,中文介绍非常少.基本全是动嘴不动手,所以也懒得再做太多介绍.只有一个 http://computer.mblogger.cn/twinsant124/posts/18266.aspx 这里.这位看来是曾经做过一些研究的. 我相信,实际做过GDS API 研究的国人一定不少,只是到底有几个人愿意把自己的研究结果公布出来.其实只要动手写写,应该问题不大. 我是从2005年初开始考虑使用gds来做开发的,目的是对文件内容进行搜索.之前曾打算用 Lucene 来实现这个功能.最后得出结论是,能用，不过并不怎么好用.一个是中文分词的问题,这个问题根据网上的资料是可以解决的,不过实现起来比较复杂.但最大问题是,在文件抽词的时候效率实在他哪个慢了.如果是一个3-4 M的PDF ,我基本要去喝杯水才能抽出来.或许有牛人说这个问题是可以解决,当然我相信问题总有办法解决.但我做的是一个完整项目,不是研究怎么提高抽词的效率.在我看来这个东西得不偿失.所以最后考虑使用GDS来实现这些功能.使用GDS 给我最大感觉就是快.而且内容相对比较可靠.毕竟如果你连google的查询都不相信,那么最好就自己写一个厉害的搜索引擎好了.
既然选定了工具,就要考虑怎么开发的问题.问题主要在于gds 本身是个桌面应用,并不支持网络搜索,至少当初不支持.现在 2.0 beta已经支持网络路径搜索了,不过说实话没具体实验过. 另外一个就是他不支持远程调用. 主要问题就在这2点上,其他都是小菜. 只要实现这2点,利用GDS 可以实现对公司内部现有文件服务器资源的一个分布式搜索,同时可以远程调用.说白了就是可以远程查询,返回结果. 同时利用GDS 自己的索引机制可以实现文件上载后索引的自动更新,基本上可以不需要考虑什么抽词和切分词的问题.只要你会存,那么查询就可以实现.我的目的就是要达到这个效果,何必研究那么多分词抽词的技术.我又不是神
在使用GDS 过程中发现了一些问题,主要是一下几点.
第一 由于我们是使用java 进行调用和存取的,发现在gds 1.0以前,使用 gds 新建立索引很不稳定. 一直找不出到底为什么,只能说这个的确是gds的一些问题,因为在 google 开发论坛上发现很多开发者都提出了这个问题.好象在某种情况下索引建立不能做完,另外一个发现的问题是 利用java 的命令进行存放文件的时候会出现不能建立索引的问题. 这个问题一直困惑我们.不过从 http://computer.mblogger.cn/twinsant124/posts/18266.aspx 蚂蚁的分析看,我觉得可能就是他所说的 Windows SPI 的问题,不过说实话这方面我一窍不通.所以也不能学哈姆雷特念念Choose or Choose .不过我运气不错,而且坚信google是会改进的.最近我们已经把应用更新到 gds2.0 beta上,就想我假设的明天会更好.哈哈,这个问题在新版本上已经不存在了。
第二个问题是删除文件的时候索引更新的问题,目前这个问题我们暂时还没有解决.主要是目前还没打算去研究这个问题,好象目前gds sdk的schema上没有删除的动作,也可能我看的还不够仔细.反正目前如果你从服务器上删除一个文件,那么更新索引就是个问题了.不过我想因该是可以的，因为在gds 自己的ui界面上绝对是能删除项目的. 所以我觉得应该是我看的还不够仔细.
第三个问题就是 sdk的版本问题,目前 gds 只推出1.0的 sdk, 2.0 beta的schema还没有推出.根据我们的测试,调用部分是没有什么变化的,但返回的结果部分非常不幸有变化.
在google 的自己开发网站上 code.google.com 有很多关于gds的插件和开发实例.实际上目前gds的开发已经有很大的规模,不知道什么时候国内有厂商或者个人能推出一个象样的插件.由于我只关注公司内部应用,而我们也不是什么软件开发商,暂时是不会有这个打算的.希望有哪个高人能推出点东西,让老外也眼睛亮一下.
