On Sun, Jun 28, 2009 at 6:20 PM, Olivier Goffart <ogoff...@kde.org> wrote:
> Le Sunday 28 June 2009, roide a écrit : > > Hi, > > In this years summer of code, I am working on the project kde > Conversation > > logging framework. (link to > > proposal<http://docs.google.com/Doc?id=dg9f3fwb_4fdg7mpfh> > > ). > > A part of the work is to modify the Kopete history plugin, so that it can > > save its chats in Akonadi. > > I have made some changes in the Kopete history plugin, > > one major change is to replace the QDomdocument with a instance History > > class( which represents a chat ). > > > > The work i have done, on the history plugin at > > branches/work/soc-logging-framework/kopete/plugins/history/ > > > > Since i hv made some changes in the history plugin codes( i have tried to > > stick as much as i can to the original algorithm), > > i was wondering if i can get some comments on the work. > > > > If i can get comments like > > "the way you have done here, is not the right way to do it, but u should > do > > like this," > > or > > "what u have done here will give rise to new bugs" > > or > > "u have not implemented this feature" > > > > or for that mattter any comment, i will be glad, because i know that > > whatever your comments will, > > they will only help me improve my work. > > > > Please take a look, when if you all get time. :) > > > > I had a quick look at the kopete history plugin code. But can you please > ellaborate on how the aknady storage works. What kind of database is it? Akonadi storage works, mainly in terms of akonadi collections, and akonadi items. What akonadi does is, it takes the data from the backendend, and changes them into akonadi collection and items. A akonadi resource is the application that is responsible, for reading the data from the backend, and and making them into akonadi collections and items. So basically, a resource is the one that is responsible for reflecting the changes in the backend. When applications ask data from akonadi server, akonadi server askes the resource to fetch the items and collections, and then gives it to application. The application can then make changes to items or collections, and tell the resource again to save back the modified item. Backend for akonadi is flexible. In my case the backend is *xml files only. So utlimately the chats are still geting saved in xml file, and in the same format as earlier. > > > The internal design of the history plugin was made for file stored in xml > files by month. Maybe you should change the design to work with akonady. In the backend, the files are still getting stored in xml files. What resource does it, it reads data from the backend(our xml files) and gives it to the application(kopete) which needs it. At the moment, i have the same logic, i m creating, one item(xml file) per month. that should be okay i guess, will ask akonadi developers. > > > > Some small comments on the code: > > > - Too many kDebug ! this would simply spam the console, please remove them > before merging. If there is some that might stay they must have the > history > plugin code Yes, i agree, there are too many kDebugs. I put them there, when i first started with the code, to understand the flow control, and how one function is calling another and etc. Will remove them, when i feel like my kopete is working fine, and i m done with the work. > > > - Since Qt4, there is a QHash class, which is faster than QMap for lookup > (if > you do not need the item to be ordered) > Will replace it wilh QHash. > > > - The error handling seems poor Will improve it. > > > - I do not know much about Akonady performence. But the whole idea of the > old > code was to load and read as less as possible (which is why each month is > separate in different files). I'm afraid about how > HistoryLogger::getHistory > will scale with huge history. Since it's still 1 files(akonadi item) per month, so i think it's okay ? > > > - in HistoryLogger::appendMessage, m_history[c]=monthHistory; > will erase all the cache fixed it. :) > > > - All operations are syncronus. (job->exec()) You probably should redesign > the plugin to get assyncronus operation whenever possible. Will do. > > > - Do we realy need a savetimer anymore? I think we do, because in order to save changes into the backend, we need to tell the resource(call itemModifyJob ), calling itemmodify job for every message dosent look fair to me. And if we are calling it only at the end of the chat, then if kopete crashes before calling itemModifyJob, we loose our chat. So i thought, it was a good idea to stick to savetimer. > > > - How does the import of the old history works? Nope, it dosnet. I am planning to work into it. > > > -- > Gof > _______________________________________________ > kopete-devel mailing list > kopete-devel@kde.org > https://mail.kde.org/mailman/listinfo/kopete-devel > -- Greetings, ro...@irc.freenode.net roideuniverse.blogspot.com
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
