OpenBrain

[Ivan Čukić]

Hi all,

Since I was mentioned, just to write a couple of words.

From my POV, openbrain could be an interesting improvement for KRunner (and 
therefore to the applications that use it as a backend - Lancelot, Quicksand). 
Although I agree that most of the time devs will not write specific application 
brain data, a global database could prove to be useful.

Currently, Runners are very specific and return just the thing that was asked 
from them, which is (more than) OK in most cases. I think that AIML could 
provide additional fuzzy results when standard runners fail. And, for simple 
things, it is easier to write an AIML file than to make a whole new runner.

The main problem I see is that it is English-specific. I do use English on my 
PC, but one of the prerequisites of something leaving kdeplayground is to have 
internationalization support.

> but basically, where should libopenbrain go?
I think that subdirectory of the applet itself is OK. IMHO, it would be wrong 
to have any application linked directly to it, when it will be available 
through KRunner. Reasons:
1. Standard API. I'm not really saying that KRunner API is a standard, but 
there's no reason in reinventing the wheel.
2. KRunner provides threading, dynamic plug-in loading and whatnot. So, no 
need for ifdefs in code to make different implementations depending on whether 
libopenbrain is found on the system.
3. ABI. libopenbrain could be changed in any way imaginable, or even replaced 
with another library, and since nothing links directly to it (apart from the 
runner), nothing needs to be recompiled.

> also libopenbrain still has std, boost, and xerces includes, they will be
> converted to qt when i get time.
I've noticed that and am really hoping it will be a thing of the past. The 
xerces can be easily replaced since SAX api is the same everywhere. As for 
boost, it'll take you some time I think :)

>  it uses berkdb43 now to instantly load all the brain data (no more waiting
> 30-60 seconds for it to load). i didn't really see a better way to do this
> w qt. tips?
Although I'm not a great fan of MySQL (even embedded) it seems that many KDE 
applications have switched to it from other DBs, so it could be a very good 
solution - it wouldn't increase dependencies.

Although there are two different approaches IIRC. Amarok uses the embedded one, 
while Akonadi or Nepomuk (I really don't remember :) ) uses a /local/ server.

Cheerio!