On Wednesday 12 October 2005 10:32, Roberto Cappuccio wrote: > Hi, > > the goal of this email is to set the directions for the next release of > Kat. I will try to answer recurring questions. > > 1. Current status of development > > Currently we have version 0.6.x in trunk and 0.7.x (Praveen's branch) in > branches. I have come to this because Praveen has been unavailable for long > time and has not been able to communicate anything about his future > availability. > This means that we will continue developing the 0.6.x series for a while. > I hope he will come back someday, but Kat's development has to continue > anyway. > Praveen started refactoring the API, documenting every class and method. > This has to be continued. I will study his code and try to port it to the > 0.6.x series. Any help with that will be really appreciated.
Are you sure that it's a good idea to change API into kat-0.6.x (which is a "stable series") ? For me this new API is for kat-0.7.0 and not for kat-0.6.x > 2. New API and new daemon > > Our major efforts have to be directed to the refactoring of the Kat API and > Kat daemon. The new GUI can wait. > We receive lots of bug reports about kded crashes and memory leaks. > It is important to notice one simple thing: the index is built upon a loop. > Loops, as every software engineer knows, are the most tricky parts of an > application because even the smallest bug is amplified by the repetition of > the code through cycles and a tiny memory leak rapidly becomes a huge hole > that swallows all the memory of the machine. > This means that this part of Kat should be designed with extreme care and > tested thoroughfully. This also means that the complexity level of that > part has to be maintained as low as possible. > The KDED crashes will be avoided creating a simple Linux daemon for Kat and > a KDED proxy for controlling it. This means that a crash of the daemon > should not propagate to the KDED. Obviously we will try to avoid any > crashes at all. > > 3. CLuceneQt > > Ben van Klinken, creator of the CLucene port of Apache Lucene, offered his > help in introducing Lucene into the Kat project. > He did more than this: he created a Qt port of CLucene. The CLuceneQt > library will be used by our new indexer. > This should increase the speed of the indexing process and also give Kat > the possibility to exploit the powerful query capabilities of Lucene. > We will continue to use the SQLite3 for storing the things that Lucene does > not handle, like the thumbnails, the metadata and the full text. It will be a good idea to use cluceneQt > 4. Problems with the new version of SQLite3 (3.2.6) SQLITE_MISUSE > > The new versions of SQLite3 are more strict than the previous ones about > the way a db handle has to be accessed. > Versions > 3.2.6 do not allow the same db handle to be used in different > threads. Since this was the "normal" behavior of our code, we will have to > change it radically in order to comply with this new policy. > > Final considerations: > Kat is an extremely young project and it is still in BETA version. > There are huge expectations about it, but people must understand that we > cannot make miracles. I also have to convince myself about that :-D > As said before, any help will be really appreciated. > > Regards ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Kat-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kat-development
