Scrap Baloo Thread Feedback

[Vishesh Handa]

On Fri, Oct 7, 2016 at 8:08 PM, Christoph Cullmann <cullmann at absint.com> wrote:
>
> I did experiments and search works with tracker, but yes, a problem is tagging,+
> which ATM doesn't work. Nor do I say that is a ready solution now, just a possibility
> to avoid having to maintain low level code with at most 1 person (how it looks ATM).
>
> And I don't propose to go that road now, but ATM I see nobody doing any other experiments.
>
> Besides, tracker is constantly maintained and used since >> 5 years:
>
> https://github.com/GNOME/tracker/graphs/contributors

ok. Baloo clearly isn't being maintained.

>
>>
>>>
>>> => That is good that we agree, but I find it very astonishing that we use baloo
>>> in its
>>> current state more or less mandatory on all that systems were it by design will
>>> fail.
>>>
>>> (and it fails if you read the bugs)
>>>
>>
>> There is a certain amount of failure, but it's not "by-design". But
>> maybe I'm not seeing things clearly.
> You yourself stated that neither 32-bit issues nor NFS nor > 32-bit inodes have any
> error handling. And that seems to have been known even during design and still
> we have this now as a framework per default used by any Plasma installation on
> systems exactly featuring that without error checking.
>
>>
>>>>
>>>>>>
>>>>>> How about requirements such as resource consumption, ease of
>>>>>> integration, search speed are taken into consideration? Come on guys.
>>>>>> We're engineers over here.
>>
>>>>> What is the argument here? If you take a look at bugs.kde.org, you see that
>>>>> people are complaining about all
>>>>> of that with baloo. I see no evidence nowhere that e.g. baloo is "superior" to
>>>>> what GNOME uses
>>>>> or any other solution (perhaps beside nepomuk, ok...).
>>
>> What tests have been to obtain the evidence?
> What tests have been done to obtain the inverse evidence? I only hear here the complaint
> about not taking requirements like resource consumption or speed into account, but
> there is ATM zero evidence that e.g. tracker is slower.
>

I did do a lot of tests during the design of Baloo. I don't have hard numbers.

Even if I didn't, that doesn't mean a decision should be made without
gathering proper data.

> And the typical error check is:
>
> void MTimeDB::put(quint32 mtime, quint64 docId)
> {
>     Q_ASSERT(mtime > 0);
>     Q_ASSERT(docId > 0);
>
>     MDB_val key;
>     key.mv_size = sizeof(quint32);
>     key.mv_data = static_cast<void*>(&mtime);
>
>     MDB_val val;
>     val.mv_size = sizeof(quint64);
>     val.mv_data = static_cast<void*>(&docId);
>
>     int rc = mdb_put(m_txn, m_dbi, &key, &val, 0);
>     Q_ASSERT_X(rc == 0, "MTimeDB::put", mdb_strerror(rc));
> }
>
> without any way to pass an error to the outside, nor any error handling code at the outside,
> as no error can ever occur that is non-fatal.
>

ok. The API isn't exported. It can be changed.

But we both seem to have different opinions of how much work this would be.

>
> Besides I don't see any documentation of the DB format, but I could miss that.
> (at least not in the git nor https://community.kde.org/Baloo)
>

There isn't any.

>
> What would be highly appreciated would be a bit of documentation what the
> different pieces do and stuff like that, even if you have no time to code.
>

If you can send me specific questions about different parts I can
answer them. For "general documentation", I don't know where to start.
I usually much prefer just going through the code.


> Greetings
> Christoph
>