On Sunday 15 March 2015 11:37:11 Pali Rohár wrote: > 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).
And here is list of all bugs related to history plugin: https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDSINFO&f1=component&f2=short_desc&j_top=OR&o1=equals&o2=substring&order=changeddate%20DESC%2Cpriority%2Cbug_severity&product=kopete&query_based_on=&query_format=advanced&v1=History%20Plugin&v2=history I would expect that all history bugs will be resolved and closed. -- 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
