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: cullm...@absint.com 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
