From Electron Cloud
Jump to: navigation, search
(New page: Strigi and Beagle are too slow. locate does not give enough information. locate does not work across the network. Swish++ is fast enough though to implement a really complete whole-syst...)
 
Line 11: Line 11:
 
* search text in open xterms/rxvts/konsoles too (often I have way too many of them open and forget what I was doing where)
 
* search text in open xterms/rxvts/konsoles too (often I have way too many of them open and forget what I was doing where)
 
* maybe quickie searches (for applications, or text in open apps) should be a different UI than searching for documents etc.
 
* maybe quickie searches (for applications, or text in open apps) should be a different UI than searching for documents etc.
 +
** actually it makes sense to combine search for apps and docs (like spotlight and the KDE4 search thingy on the start menu), but put the search for text in open windows into the window list (the one that flies out from the upper-right corner).  So those two aren't actually related: documents and apps are indexed, but the "open windows" search is on-demand: the apps need to support an API for doing that.
  
 
Of course it needs to integrate into the "universal command line" some day.  (link suggestions show up as you are typing)
 
Of course it needs to integrate into the "universal command line" some day.  (link suggestions show up as you are typing)

Revision as of 20:34, 10 March 2009

Strigi and Beagle are too slow. locate does not give enough information. locate does not work across the network. Swish++ is fast enough though to implement a really complete whole-system search solution. I even used it that way once at a previous job. (It must be native code, not Python/C#/Java etc!)

Here are the features I want:

  • index ALL files, not just my home directory
  • include symbols in libraries (.a and .so)
  • use plugins or external parsers to convert unsupported things (like Word documents and PDFs) to text for indexing (this is the Swish++ approach)
  • the client can search only the local machine, or can distribute the same query to a collection of machines on the network, and aggregate results, showing where the found documents are located
  • security features like slocate (users can optionally not be allowed to search files they aren't allowed to read)
  • re-index files as they change (get notifications via inotify or something)
  • cross-platform (Linux, Mac and Windows) (on mac maybe just tie into spotlight, make the database available across the net)
  • search text in open xterms/rxvts/konsoles too (often I have way too many of them open and forget what I was doing where)
  • maybe quickie searches (for applications, or text in open apps) should be a different UI than searching for documents etc.
    • actually it makes sense to combine search for apps and docs (like spotlight and the KDE4 search thingy on the start menu), but put the search for text in open windows into the window list (the one that flies out from the upper-right corner). So those two aren't actually related: documents and apps are indexed, but the "open windows" search is on-demand: the apps need to support an API for doing that.

Of course it needs to integrate into the "universal command line" some day. (link suggestions show up as you are typing)