On Wednesday 11 March 2015 17:13:16 kaushik wrote: > On 11 March 2015 at 03:28, Joshua Joseph <joejo...@gmail.com> > wrote: > > On Fri, Mar 6, 2015 at 12:02 AM, kaushik > > <roideunive...@gmail.com> wrote: > >> Hi Joshua, > >> > >> Welcome to Kopete. > >> > >> Understanding the existing plugin code and redesigning it > >> will be the best way to go for it. However understanding > >> the existing code will not be that easy. You will need > >> some familiarity with these Kopete::Contact and > >> Kopete::MetaContact. > >> > >> The logic inside HistoryLogger.cpp is not that difficult to > >> understand. If you see huge methods, that is probably > >> because it also contains the logic of parsing the history > >> log ( which is read as QDomDocument ) and appending the > >> incoming messages to it. Moving the logic to its own class > >> or a different method will shrink the code and make it > >> more readable. You can use a History object instead of the > >> QDomDocument, or anything else you might want. > >> > >> Once you are a little familiar with the existing plugin > >> code and If you need any help in understanding the logic, > >> just ping us and we should be able to help. > >> > >> Thanks, > >> Kaushik > >> IRC - roide > > > > Thanks Kaushik. > > > > I have gone through the source code. The history1 plugin > > seems very well structured. Looking at the bug list, the > > one of the requested features is the ability to import > > chats from more IM applications. > > > > I think the core of this project will be based on > > restructuring/rewriting the History plugin, and also expand > > it to be able to import history from more external sources. > > That sounds like a good way to do it. If I were to define the > goals of the project, on the similar lines as Pali described > it, It would be : > > i) Increase efficiency - better load time and search support > ii) Support for HTML messages and Multiuser chat. > iii) Import history from other sources > > At the same time, to make the history plugin code more > readable and better documented. > > In order to achieve these goals if we need to rewrite/new > plugin it should be acceptable if it can be done without > rewriting the existing plugin it should be acceptable too. > However rewriting the plugin looks like a cleaner way to do > it. > > Thanks, > Kaushik > IRC - roide
Now I think that history plugin should be rewritten from scratch. And new code must be clean and easy to read/understand. Maybe it make sense to have abstract history API and then implement history read/write "driver". (This will allow to change history storage driver in future if needed for some reasons). And i) search support + ii) html messages, multiuser chat must be designed at same time. If you do not do it, then we will have another plugin with bad support either for i) or ii). -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
