Scrap baloo?

[David Edmundson]

On Wed, Sep 28, 2016 at 4:03 PM, Christoph Cullmann <cullmann at absint.com>
wrote:

> Hi,
>
> > Hi,
> >
> > On 28 September 2016 at 02:36, Christoph Cullmann <cullmann at absint.com>
> wrote:
> >> any update?
> >
> > Yep. In all the happennings of the week I just forgot to write this
> email.
> >
> > If Baloo is going to be an integral part of the Plasma experience, do
> > we really want to depend on an external project where we don't have
> > control (and indeed, sentiments may prevent unrestricted contributions
> > based only on merit). This is the political reason why I don't want to
> > depend against Tracker. The technical reason is that it's based on
> > SQLite, which is incredibly slow compared to what we do now.
> I don't see really that it is slow compared to what we do, if you have
> benchmarks
> for that, I would be pleased to see them.
>
> >
> > At the same time, LMDB needs to be replaced, and fast. I'm building a
> > new KVDB as an university project (it should be able to do 256GB
> > indexes on 32bit machines), and if that doesn't work out there's
> > Sophia (http://sophia.systems/). I'll be evaluating both as a
> > replacement to LMDB.
> Do we really want to maintain a own DB system?
> IMHO that will never work out, all DB systems around need more maintenance
> power
> than we have.
>
> >
> > Vishesh also wanted to separate out the engine and make it public API
> > (apparently other projects want to make use of it as a general data
> > storage library - and the engine offers fulltext search capabilities
> > and other fancy logical operators that make it particularly
> > attractive. My plan is to move towards that, and eventually also not
> > only index files but also other kinds of objects - contacts, or
> > people, for example.
> >
> > I don't want to move back into the "semantic desktop" idea at all, but
> > I do want some sort of infrastructure that allows for an "action on
> > object" metaphor - file objects can be opened with an application,
> > people objects can be sent mails, and so on.
> >
> > Hope this makes sense.
> I still not see how that should work out, atm, IMHO facts are:
>
> 1) baloo is not maintained
> 2) lmdb will e.g. never work for us on NFS homes and the code needs major
> overhaul
> to handle errors (which you confirm)
> 3) you said you have "some time" left to maintain it, but you now propose
> in addition to maintain
> Baloo to write a DB system from scratch, I don't really see that working
> 4) tracker on the other side is maintained and in use and we can share the
> index data with GNOME and others
>
> I really doubt that doing the work to remove lmdb, replace it with an "own
> one" and then starting
> to fix all other issues (like indexer running amok, broken file
> extractors, ...) will work out if
> we don't clone some more people.
>
> But that is only my opinion.
>

Generally speaking, in terms of Plasma feedback, Baloo doesn't come up
/that/ much.
I'm sure there's stuff in the bug tracker, but we don't have the big public
problem that we used to have.

I think your problems are exagerrated because of the NFS mount.

The only problem we have is the runner bringing down the shell when we have
the corrupt database - and from the comments above, that should be
catchable.

--------

Questions:

Tracker doesn't look at xattrs at all.

At which point we would need to think about migration.

This is possibly solvable with a patch in tracker. The tracker maintainer
(in 2014) sounds like he would be in support of it: https://mail.gnome.org/
archives/tracker-list/2014-September/msg00045.html
and there is a writeback module in tracker.

-----

A sizable part of your argument is based on problems with NFS . SQlite
(that tracker uses) will surely have the same problems.
Surely If file locks don't work, then file locks don't work....?

-----

A big reason tracker seems faster/smaller than baloo is that it only
indexes the main XDG folders: Documents/Music/Pictures/Downloads by
default.
Would you change that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160928/9cc7db92/attachment.html>