Scrap Baloo Thread Feedback

[Vishesh Handa]

Hey

On Fri, Oct 7, 2016 at 6:34 PM, Christoph Cullmann <cullmann at absint.com> wrote:
> Hi,
>
>> On Fri, Oct 7, 2016 at 5:58 PM, Christoph Cullmann <cullmann at absint.com> wrote:
>>>
>
> 1) No handling of DB errors beside asserting
> 2) No handling of errors in the extractors (e.g. see the fixes I did, all extractors will need more of that)
> 3) No handling of NFS/large inodes/inconsistencies => crash
>
> In the end, in my opinion, you can rewrite close to all parts dealing with the DB or
> any other thing internally. If ever any thing gots inconsistent, ATM you are doomed, forever,
> if not by luck my new startup code deletes the index, then you live again until it is reindexed.
>
>>
> I am not sure, I am all for removing complete indexing and use a other indexer
> like tracker to exactly avoid the excurse into DB world and how to handle it
> in a safe way with close to zero person manpower.
>

It's avoiding the problem and hoping for the best, without any experiments.

>
> => 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.

>>
>>>>
>>>> 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?

>
>>
>> Yup, you have. It's awesome. I no longer have the motivation to work on Baloo.
> Thanks, but that makes me very sad, btw.
> Baloo came up to replace nepomuk, which was dead because it had too many bugs and all maintainers left.
> Now we have baloo, which has many bugs, some even by design, and the maintainer left, too.
>

Actually, Nepomuk was not dead. I was maintaining it. I killed it
because it had too many structural problems.

This is how the open source world works. People work on projects and
when it no longer scratches their itch (I no longer use Baloo), they
loose interest. This is "supposed" to be a hobby.

>
>> (This is why they run on a separate process)
> That doesn't help, it just OOMs your system => dead, it needs resource restrictions,
> which is tricky to get right.
>

You're right. It needs a better thought out solution. A separate
process is the bare minimum.

Btw, have you looked if Tracker actually does any of this?

>> My hostility was because the proposal ignores key points such as -
>>
>> * Indexing Speed
>> * Search speed
>> * Database size
> => If you look at the bugs, people complain we are inferior and I see not
> that the proposal ignores it, I just see not how to compare, given there are no
> hard facts that we are faster than e.g. tracker in any way.
>

Data can be gathered about it. Not all data is publicly available.

>> * Ease of use with our existing components
> My proposal did not change the interface at all, it has zero impact on "ease of use".
>
>> * Ease of fixing problems in the code
> My estimate would be: rewrite close to everything. Even the basic 64-bit int id won't work
> with 64-bit inodes, each DB call must be touched to check for errors, at each place
> one will need to check for potential inconsistencies and exit gracefully...
>

I don't follow why everything needs to be re-written? Am I missing
something or do we just need to check for more errors and use a higher
integer id? This certainly doesn't seem super trivial, but it sounds
like less work than implementing a shim on top of Tracker.

I could be wrong.

>>
>> Baloo has certain speed requirements if it is to be used with krunner,
>> and we want instant feedback. This was an integral requirement.
> I doubt e.g. tracker has different requirements, as it is used in similar places by GNOME.
>
> But all that left besides, have you an proposal how to fixup the current situation?
> Are you willing to invest some work to fix the current issues or an idea what
> would be a good way to tackle them?
>

I probably will not work more in Baloo.

I'll have to investigate the problems a bit more. From the cursory
look of this thread, it doesn't seem that the problems are that dire.
But I may not be reading into it correctly.


--
Vishesh Handa