Projects/KDE PIM/Development/Mobile/ResourcesCESearch

On Windows Mobile 6.5 (CE) Kontact Touch has a resource problem, the searching and indexing is done via strigifeeder and strigidaemon.

Next steps:

• find all places where search is needed

1. real search dialog (_not_ quicksearch)
2. to-field autocompletion
3. ? Calendar?

• how much memory does strigidaemon actually use?
• check if clucene used by strigidaemon cannot be tuned to use less memory
• implement a display of the last index run, e.g on the search page
• implement a button to trigger a manual index, e.g. on the search page (both can be reused once we come up with an idea when the indexer should run.)
• Can we reliably see if the device is under low load, e.g. if only one or no frontend is running?

Options as tokoe saw them 2011020914:32:

1) A UI option to switch strigi_feeder between online/offline mode

 pro: The strigi_feeder in offline mode wouldn't index anything until it
      is switched back to online mode. So it would take away pressure on the
      device during initial sync, since CPU and I/O usage is reduced.

 contra: Since recent data are not indexed with strigi_feeder in offline            
         mode, some internal searches might not return the correct, or better 
         said 'expected', data. Switching the strigi_feeder to online mode
         automatically when a search is started is not really an option,         
         because feeding the new data to strigidaemon takes a while, so they
         won't be included in the current search results.

 costs: We have to extend strigi_feeder to correctly record actions during  
        offline mode and replay them when switched to online mode.
        Furthermore we need options in the UI to switch the mode of the 
        strigifeeder (Ideas from Björn Balazs?).

2) IDLE detection in strigidaemon with automatic shutdown

 pro: Afaik strigidaemon uses lots of memory when running, so
      stopping strigidaemon whenever no indexing or search is done,
      should provide some free memory on the device.

 contra: Searches are done quite often (e.g. the autocompletion in mail        
         composer) and strigi_feeder will index data as soon as something 
         changes (e.g. read flags in emails), so I doubt that strigidaemon
         will have long idle sessions. Strigidaemon might cause additional     
         costs during its startup/shutdown phase.

 costs: We have to implement an idle detection in strigidaemon
        (non qt-based!) and a clean shutdown procedure.
        Furthermore we have to extend akonadiserver to handle the      
        disappearance of strigi dbus interface gracefully and restart the 
        strigidaemon on demand. This needs a lot of testing!

It would be possible to combine 1) and 2), but this will increase the number
of side effects, so much more testing is needed.