Scrap baloo?

[Christoph Cullmann]

Hi,

> Hi,
> 
> On 16 September 2016 at 01:04, Christoph Cullmann <cullmann at absint.com> wrote:
>>>> => Opinions?
>>>
>>> It would be nice to hear what Vishesh, Pinak and Boudhayan think about
>>> this.
> 
> I prefer getting familiar with the code as well as having a mile-high
> view of what does what before I start laying down code, hence why I
> haven't submitted a single line of code yet. What I have been doing so
> far, though...
> 
> I've been trying to track down the history of Baloo and which part
> does what. Also looking at past backends and what decisions were taken
> that ended up with Baloo in the state that it is today.
> 
> I spoke to Pinak privately and he's volunteered to write some
> documentation over the weekend. I've also been looking at why Baloo
> doesn't use something like Xapian (which is made for use-cases like
> Baloo) and I was pointed to this:
> https://community.kde.org/Baloo/XapianProblems. Looks like the whole
> rationale boils down to - we have so much custom code over Xapian we
> might as well just have custom code over LMDB instead, it's faster.
> 
> I have a long journey (an actual journey, flights, buses, the whole
> deal) ahead of me and I'll have some time to think about a long-term
> plan for Baloo. It may involve killing it and working against Tracker,
> or it may even involve putting more custom code into it. Whatever the
> decision is, I'm going to try and justify the effort involved before I
> present my plan to everyone here.
> 
> So far I'm leaning towards either a safer wrapper around LMDB or a
> custom Key Value Database (basically a reimplimentation of Bitcask in
> C++) for which we can ensure the presence of a Qt-friendly "safe" C++
> API, to armour the database code. I actually think Baloo in its
> current form is very well designed; for example, using the filesystem
> as a database is pure genius. It's just sloppily executed and the code
> quality could do with... some work.
> 
> I think wrapping the Database bits into a more modular and reusable
> component was part of Vishesh's plans anyway, because other bits of
> KDE would like to re-use them.
> 
> Anyway, enough rambling. I should have something in a few days.
sure, take your time to look at it, its nothing we need to decide in a few days.

Just as prove of concept that tracker can do a lot of stuff and
we still can keep the public API we have (perhaps beside the indexerconfig stuff,
beside if we start to query tracker configs, too) I hacked a bit more on
my tracker baloo variant.

https://quickgit.kde.org/?p=clones%2Fbaloo%2Fcullmann%2Ftbaloo.git

Stuff like:

baloosearch "type:Audio modified<=2016-12-12" -d /home/cullmann/data

works now again, still missing is handling of generic properties (which then
need to be mapped to the matching sparql names and tags) and the filling
of the KFileMedaData from the tracker DB.

But I think I will only invest time in that after we all came to some 
consensus what to do at all, just wanted to show that tracker stuff is feasible
without a great amount of work with even keeping the API intact enough
that we would have some transition possibility without breaking BC/SC.
(modulo query string conversion glitches)

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234