Web lists-archives.com

Re: Scrap Baloo Thread Feedback




Hi,

> Hey guys
> 
> I was told there is a thread about scrapping Baloo. All Baloo
> discussion used to happen on kde-devel and that's where the review
> requests go. It's the only reason I am still subscribed to kde-devel.
That is nice, but given baloo is a framework, that was unexpected, sorry.

> 
> I must say, the thread is overall quite disappointing. There seems to
> be no scientific or rationale cost based analysis of this. How about a
> list of requirements and priorities are drawn up and then possible
> solutions are evaluated according to it?
Actually, the bugs.kde.org page tells you the facts: The bug number
was constant increasing since > 1 year. The thread lists some other facts
what is wrong ATM and should be fixed.

And to replace baloo with something else based for example on tracker was just one
proposal.

An other was to fix baloo + port it to an other database.

> 
> Right now, random requirements such as NFS and 32bit systems are
> coming up. Are these really that important? I specifically designed
> Baloo to not care about both network mounts and 32-bit systems. Yes,
> Baloo has bugs and it won't handle more than 32bit-inodes. These
> things, as all others, can be fixed. It's really a question of what is
> important. Lets not target the outliers. Many of these decisions were
> deliberately taken.
That are no random requirements, sorry, you could call it random restrictions, too.
That is not that productive, or?

1) 32-bit systems are still there and if that is a design decision to NOT support them,
that is ok, but then bad for Plasma, no official support for 32-bit systems, baloo is IMHO
the only framework with such requirements. And I see not that we have hinted any distro
that they shall not compile it for 32-bit.

2) No NFS: Ok, fair game, but then, it should check that and disable itself completely if $HOME
where the db is stored is a NFS, can live with that, too, but not with the current "we random
crash" behavior. => That is a user experience we don't want, or?

3) > 32-bit inodes: That is normal and should work, but even if it should not: Atm you get inconsistent
and then later assertion fails or crashs.

=> I can live with all restrictions but the current handling of them, that always ends in "crash" is
IMHO not that acceptable. But that is "my" opinion, that might vary in the eyes of others.

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

I fixed in a few days more bugs than were fixed in 1 year and triaged more than ever, still a lot is to be done.
(and I did really not do a lot, just remove things like 'self destruct if index > 5GB' or 'crash for ever on
db corruption')

A graph tells more than words:

https://bugs.kde.org/reports.cgi?product=frameworks-baloo&output=show_chart&datasets=CONFIRMED&datasets=ASSIGNED&datasets=REOPENED&datasets=UNCONFIRMED&datasets=RESOLVED&banner=1

Given the current open bugs, one will need to:

1) review all extractors, they have still close to zero error handling and will just crash or OOM you on bad files
2) review + fix the complete data base handling to handle errors and perhaps swap the DB
3) fix the indexer to have some resource limits to avoid OOM and Co. if e..g extractors fail
...

Therefore there was my proposal, given we lack manpower, to implement baloo API on top of e.g. tracker to avoid all this
and let tracker handle that.

To check if that is at all feasible, I did some quick and dirty implementation (still modulo filling of the metadata in the results + tagging,
which is a problem, but that was only to see if e.g. search works)

https://quickgit.kde.org/?p=clones%2Fbaloo%2Fcullmann%2Ftbaloo.git

That is just a proposal and then I started the discussion.

Until now, we have one other proposal, by Boudhayan, to fixup baloo.

> 
> (If the discussion continues on kde-frameworks-devel, I probably won't see it)
I won't see it on kde-devel, please, frameworks related stuff should really
be discussed on the frameworks list.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann@xxxxxxxxxx
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234