From kde-devel Wed Feb 23 21:53:29 2005 From: Manuel Amador Date: Wed, 23 Feb 2005 21:53:29 +0000 To: kde-devel Subject: Re: A search service for KDE Message-Id: <1109195609.30814.39.camel () master ! amauta> X-MARC-Message: https://marc.info/?l=kde-devel&m=110919528522746 Before I continue, let me say that the KFile plugin for HTML files is using a wrong regular expression to get the title from HTML documents. It is greedy and it should not be. thus Zjsadflkasjflksajdfl gives: Zjsadflkasjflksajdfl as a result. Consider that a quick bug report =) El mar, 22-02-2005 a las 17:32 +0100, Mikolaj Machowski escribió: > Dnia sobota, 19 lutego 2005 00:37, Manuel Amador napisał: > > Core functionality is pretty much done right now, after 8 days work. I'm > > currently writing a simple client application a la Beagle, which will > > support DCOP for other client applications to use and integrate. > > > > Basically what I wanted to ask is: > > - any pointers or ideas to keep in mind? > > All archives including OO.o and KOffice files, mail. I would need ways to extract properties and text from those files. As for mail, that kind of thing is going to be postponed for a future release, because we have the notion of information spaces: - filesystem (which is what is being implemented now) - mail - conversation logs - web cache/history and I still haven't figured out how to get information from the other spaces, since they are (as you can probably see right now) mostly application-dependent. > Possibility to exclude directories (if it is not done now). The system automatically excludes "inappropriate files" right now, them being /media /mnt and a couple of system mounts like /dev, /sys and /proc. Other than that, although I might make that configurable on a system-wide basis, I do not see a reason why you would like to exclude them. In the future, the system will index removable media and catalog files on them as well, letting you know in which CD you put file X (or XXX for that matter =). > KIO_slave for data presentation. please clarify this requirement =) > Virtual folders keeping queries and updating them - both regurarly and > on demand. While the core system does not make this possible right now (no support for async queries both in the core system and in the currently existent application interfaces (XML-RPC!)), I do think this would be a meritous goal. I have not written the live indexing components, for the moment all it does is crawl a la updatedb. This is planned for the first official release though. This will also need inotify, as KDirWatch is too cumbersome and low-level, and does not support recursive notification, and other notification systems are also subpar. Would 1GB index size be okay for 10GBs of stored data? > > > - would people here support integrating it into KDE? How would that be > > accomplished best? I'm thinking KFind should support it by default > > (there's nothing mysterious about the interface/API to the search > > server, it's just an XML-RPC server) > > IMO Python-bindings requirement is big no-no for inclusion into core > KDE. Kdeextragear project or completely separate kde-apps entry is much > more probably. Never said anything about kdecore. But I would surely support that the core KDE apps transparently make use of this project wherever it is installed, such as e.g. detecting if it is installed and automatically putting a search box in Kicker that presents a short popup list of results and a More... link which would open the main application window. or making kfind ... well, kfind is too complicated to use anyways =). > Kdeextragear gives more freedom when advancing project - not tied with > KDE roadmap and other 'anchors'. It can be excellent playground for data > format file into future KDE (C++) tool. > > m. > -- Manuel Amador <rudd-o@amautacorp.com> Amauta >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<