[Kde-pim] Restructuring Baloo

[upscope]

On Friday, September 19, 2014 04:45:29 PM Vishesh Handa wrote:
> Hey guys
> 
> In preparation of making Baloo a framework we've been reevaluating
> what exactly we provide. It turns out that Baloo was doing 3 things -
> 
> 1. Providing an abstract searching library which others could
> implement 2. Providing a file indexer
> 3. Providing a mini library to read/write tags and ratings
> 
> This is a grand simplification as there are some more minor parts.
> 
> 1. Abstract Search Library
> This library provides a collection of AND/OR and (key, value,
> comparison) fields which can be grouped together to create any
> complex query. Additionally, it provides the concept of a
> "SearchStore" which implements the processing of the query and
> returns the results.
> 
> We currently have 5 provides of these SearchStore plugins Files,
> Emails, Contacts, Notes and Calender. The last 4 are for PIM.
> 
> You choose the plugin you want the query to run against by setting a
> string such as "Email", "File" , "Contact", etc.
> 
> 2. Providing a File Indexer
> There isn't much more to say. This is one of the core parts of Baloo -
> File Indexing.
> 
> 3. Reading/Writing Tags
> This is inside Baloo as it was there in Nepomuk, but there really
> isn't anything Baloo specific. It's just a bad wrapper over the
> setxattr system calls.
> 
> Proposal:
> * Make the Baloo project just be a file indexer + file searching
> solution. * We can move the reading/writing of tags to KFileMetaData
> as it is "metadata" related.
> 
> I would also like to get rid of this "Abstract Search Library". This
> library is currently used in the following places -
> * KRunner Baloo plugin - It doesn't matter over here since we make a
> separate call each time to every different SearchStore. The same API
> doesn't make much of a difference.
> * Dolphin - For constructing a file specific query.
> * Akonadi - They do not use this Baloo "search library" on the client
> side. They have their own implementation which is converted to json
> sent to Akonadi and forwarded to a Akoanadi Search Plugin. One of
> these plugins is provided by Baloo which converts the Akonadi Query
> to the Baloo Query.
> 
> Given that only Akonadi is using this Abstract Search Library, but has
> their own search library as well, it seems wise to get rid of ours. I
> can create an akonadi-search repository and move the code over there.
> We spoke during the PIM bof in Akademy and searching is eventually
> going to become more tightly integrated with Akonadi anyway.
> 
> Side note: Searching through Baloo is slightly faster because it does
> not go through Akonadi but directly accesses the index. This will not
> be lost as we still have custom libraries on top of the index to do
> that (baloo/src/pim/lib)
> 
> Dolphin and KRunner can use a specialized file searching API instead
> of a generic one.
> 
> tldr -
> * Baloo will just be a file index + file search
> * Tagging will be moved to KFileMetadata
> * Akonadi parts will be moved in PIM
> 
> Opinions?
As far as I'm concerned all you need is a way to turn it off completely. 
Or a way to only run it manual (cron job or a setting that says only run 
it once every month, week etc). 

Russ
-- 
openSUSE 13.1(Linux 3.11.10-21-desktop x86_64|
Intel(R) Quad Core(TM) i5-4440 CPU @ 3.10GHz|8GB DDR3|
GeForce 8400GS (NVIDIA-Linux-x86_64-340.32)|KDE 4.14.1

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/