#2644 NORM Untriag: Need incremental search in Journal

Zarro Boogs per Child bugtracker at laptop.org
Thu Aug 2 16:50:55 EDT 2007


#2644: Need incremental search in Journal
------------------------------+---------------------------------------------
 Reporter:  Eben              |       Owner:  tomeu    
     Type:  defect            |      Status:  new      
 Priority:  normal            |   Milestone:  Untriaged
Component:  journal-activity  |     Version:           
 Keywords:                    |    Verified:  0        
------------------------------+---------------------------------------------
 The Journal design assumes some level of incremental search.  Obviously
 the interval upon which this search is performed will be limited by
 performance, but there are a few basic rules we can follow to make it work
 pretty well in the general case.

  1. Check on some interval t to see if the search string has changed. If
 it has, fire off a new search.  Checking for change means it will work
 both when entering and when deleting characters.  It's also important to
 do this on an interval, so that it can perform partial searches while the
 user continues to type, not just on a delay after typing stops.  Decide t
 based on performance; it can be variable with query length. That is, make
 t smaller as search string increases in length to narrow in more quickly
 on results.

  2. Perform a search immediately upon an 'enter' keystroke.  There's no
 need to force them to wait for any interval to pass if they explicitly
 initiate the search.

  3. As soon as the search string becomes null (cleared), immediately
 perform the search omitting the string (using only the selected filters),
 so that the Journal returns to a clean state before they begin typing a
 new query string.

 It may be worth rigging up a system by which each incremental search is
 performed on the previous set of search results, instead of from scratch.
 This would seriously improve performance (from n*m to, well...something
 better than that...n*log(m) average case?  My algo is rusty and there are
 a ''lot'' of factors to consider, not to mention that doing combinatorics
 on the space of the english language is a nightmare.)  You'd actually need
 a cache stack, so you can handle changes in cursor position and deletions.
 Oh, and all that takes up lots of RAM, which we don't have, anyway...

 Oh well.  The basics of an incremental search are very much needed.

-- 
Ticket URL: <http://dev.laptop.org/ticket/2644>
One Laptop Per Child <http://laptop.org/>



More information about the Bugs mailing list