[Kde-pim] Restructuring Baloo

[Vishesh Handa]

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?

-- 
Vishesh Handa
_______________________________________________
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/