This design sounds pretty good, simplifies the architecture quite a bit and will definitely make Baloo more easily extensible and testable. I can help around in implementing this :)
-- Pinak Ahuja On 6 June 2015 at 04:36, Vishesh Handa <[email protected]> wrote: > 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 <<
