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

Reply via email to