Hey Pinak I was trying to figure out how re-organize the Baloo indexing architecture. It's currently, as you have seen, a little messy with the 2 queues - BasicIQ and FileIQ.
Please run through the design below and tell me what you think? * There are currently 5 different indexing modes - 1. First Run Indexing 2. Modified File Indexing 3. XAttr Changed Indexing 4. New File Indexing 5. File Content Indexing Currently the Basic IQ takes care of 1-4, while the FileIQ takes care of 5. I would like to split each of these modes up separately and keep their logic separate instead of mixing them together. Plans of Action - 1. Create separate QRunnable based classes for each of these 5 different modes. Each mode requires different things to be checked and the index to be updated differently. These classes will be simple serial execution, without any overhead of the event loop. 2. Get rid of the IndexScheduler and FileIndexer classes. 3. Create a new scheduler classes which is basically 4 string lists (1-4 modes) of files. It decides which mode should be given priority, and only that QRunnable will run. We can make it run more than one runnable but since they all take a write lock on the db, they will just block. The decision structure can be identical for now. Always run 1-4 modes, only run 5 when not on battery. This scheduler can also export which mode is currently running, and optionally which files are in which mode. This way `balooctl` can give info about what is going on. 4. File Content Indexing will also be a QRunnable, it will still however have the identical code where it communicates with an external process, and the indexing happens there. We will still need to expand this quite a bit so that we can expose the current file and what not. (your gsoc) I can probably implement all of this in a day. Let me know what you think? ---- There is also - 6. Full file system check for updates we missed 7. Clean the index cause config changed (baloo_file_cleaner) It seems with this architecture we can easily expand the scheduler to handle more modes? Also each mode can easily be independently tested. -- Vishesh Handa
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
