<div dir="ltr"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 4:03 PM, Christoph Cullmann <span dir="ltr"><<a target="_blank" href="mailto:cullmann@absint.com">cullmann@absint.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Hi,<br>
<span><br>
> Hi,<br>
><br>
> On 28 September 2016 at 02:36, Christoph Cullmann <<a target="_blank" href="mailto:cullmann@absint.com">cullmann@absint.com</a>> wrote:<br>
>> any update?<br>
><br>
> Yep. In all the happennings of the week I just forgot to write this email.<br>
><br>
> If Baloo is going to be an integral part of the Plasma experience, do<br>
> we really want to depend on an external project where we don't have<br>
> control (and indeed, sentiments may prevent unrestricted contributions<br>
> based only on merit). This is the political reason why I don't want to<br>
> depend against Tracker. The technical reason is that it's based on<br>
> SQLite, which is incredibly slow compared to what we do now.<br>
</span>I don't see really that it is slow compared to what we do, if you have benchmarks<br>
for that, I would be pleased to see them.<br>
<span><br>
><br>
> At the same time, LMDB needs to be replaced, and fast. I'm building a<br>
> new KVDB as an university project (it should be able to do 256GB<br>
> indexes on 32bit machines), and if that doesn't work out there's<br>
> Sophia (<a target="_blank" rel="noreferrer" href="http://sophia.systems/">http://sophia.systems/</a>). I'll be evaluating both as a<br>
> replacement to LMDB.<br>
</span>Do we really want to maintain a own DB system?<br>
IMHO that will never work out, all DB systems around need more maintenance power<br>
than we have.<br>
<span><br>
><br>
> Vishesh also wanted to separate out the engine and make it public API<br>
> (apparently other projects want to make use of it as a general data<br>
> storage library - and the engine offers fulltext search capabilities<br>
> and other fancy logical operators that make it particularly<br>
> attractive. My plan is to move towards that, and eventually also not<br>
> only index files but also other kinds of objects - contacts, or<br>
> people, for example.<br>
><br>
> I don't want to move back into the "semantic desktop" idea at all, but<br>
> I do want some sort of infrastructure that allows for an "action on<br>
> object" metaphor - file objects can be opened with an application,<br>
> people objects can be sent mails, and so on.<br>
><br>
> Hope this makes sense.<br>
</span>I still not see how that should work out, atm, IMHO facts are:<br>
<br>
1) baloo is not maintained<br>
2) lmdb will e.g. never work for us on NFS homes and the code needs major overhaul<br>
to handle errors (which you confirm)<br>
3) you said you have "some time" left to maintain it, but you now propose in addition to maintain<br>
Baloo to write a DB system from scratch, I don't really see that working<br>
4) tracker on the other side is maintained and in use and we can share the index data with GNOME and others<br>
<br>
I really doubt that doing the work to remove lmdb, replace it with an "own one" and then starting<br>
to fix all other issues (like indexer running amok, broken file extractors, ...) will work out if<br>
we don't clone some more people.<br>
<br>
But that is only my opinion.<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Generally speaking, in terms of Plasma feedback, Baloo doesn't come up /that/ much.<br>I'm sure there's stuff in the bug tracker, but we don't have the big public problem that we used to have.<br></div><br>I think your problems are exagerrated because of the NFS mount.<br><br></div><div class="gmail_extra">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.<br><br>--------<br></div><div class="gmail_extra"><br><div class="gmail_quote">Questions:<br></div><br><div class="gmail_quote"><div></div><div>Tracker doesn't look at xattrs at all.<br></div><div><br>At which point we would need to think about migration.<br></div><br><div>This is possibly solvable with a patch in tracker. The tracker maintainer (in 2014) sounds like he would be in support of it: <a target="_blank" href="https://mail.gnome.org/archives/tracker-list/2014-September/msg00045.html">https://mail.gnome.org/<wbr>archives/tracker-list/2014-<wbr>September/msg00045.html</a><br></div><div>and there is a writeback module in tracker.<br></div><div></div><div></div><div><br>-----<br><br></div><div>A sizable part of your argument is based on problems with NFS . SQlite (that tracker uses) will surely have the same problems. <br>Surely If file locks don't work, then file locks don't work....?<br><br></div></div>-----<br><br></div><div class="gmail_extra">A big reason tracker seems faster/smaller than baloo is that it only indexes the main XDG folders: Documents/Music/Pictures/Downloads by default. <br></div><div class="gmail_extra">Would you change that? </div></div></div>