On 16 June 2015 at 10:25, Joshua Joseph <joejo...@gmail.com> wrote: > > > On Tue, Jun 16, 2015 at 12:00 AM, Pali Rohár <pali.ro...@gmail.com> wrote: > >> .. I do not know if these messages should be >> > > logged or not. >> > >> > I think these messages (user joined, left) should be logged. They can >> > provide >> > context when someone is reviewing the history later. >> > >> >> https://github.com/josh-wambua/kopete/blob/proposal/proposal.md >> >> I looked at updated info in git and I'm still not happy with it... >> >> First storage structure does not allow to save any (relevant/useful) >> information about messages what Kopete::Message class supports >> >> >> http://api.kde.org/4.x-api/kdenetwork-apidocs/kopete/libkopete/html/classKopete_1_1Message.html >> >> > I updated the page to add some relevant message information. >
I am not really sure if the session table will be useful, maybe a word or two why we need it and how we will use it? Also using File in the history table does not look good. > > >> And second I still do not see how you want to handle multi user chats >> correctly. You are adding session to chat message, but >> Kopete::ChatSession is not useful here. It is destroyed if you close >> chat window, but some multi user chats are still active (e.g. in skype) >> even if you close chat window. Something similar will be in IRC plugin >> too (I believe). >> > > I am in communication with Kaushik about that, so we can see how best to > handle multi user chats. > > I remember we discussed about the Group table - while it makes sense for group chat - It won't work for IRC chats. For IRC chats the "chat room" is going to be fixed, so you might want to include Group type that could define the nature of the group. Can you add that design in the readme. I would also suggest take a look at how kopete handles group chats for different protocols and add the different cases we will need to handle in the readme with the protocol name. >> Also I do not know where or how will be stored something like jabber >> resource name... >> >> Also don't miss this one out. > As I told at the beginning of GSoC, rewriting history plugin is not easy >> and new plugin should have fixed all design problems of previous >> implementations. And first I want to see working storage format... >> >> -- >> Pali Rohár >> pali.ro...@gmail.com >> >> _______________________________________________ >> kopete-devel mailing list >> kopete-devel@kde.org >> https://mail.kde.org/mailman/listinfo/kopete-devel >> >> > > > -- > Thanks, > Joshua > > > _______________________________________________ > kopete-devel mailing list > kopete-devel@kde.org > https://mail.kde.org/mailman/listinfo/kopete-devel > >
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
