On Fri, Oct 7, 2016 at 8:08 PM, Christoph Cullmann <cullm...@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
>
