Quick comments before I update the schema: On Wed, Jun 17, 2015 at 2:24 PM, Pali Rohár <pali.ro...@gmail.com> wrote:
> Hi, > > still I see there couple of problems: > > 1) Why is group_type needed which just specify protocol? Protocol is > already present in messages table. > > 2) I would prefer to have integer primary key for groups and also > referenced it from messages table (instead string). I would expect that > some SQL databases could have problems to use "unknown" string type as > primary key. > > 3) jabber_resource column is totally useless... first storage should be > protocol independent and second it is resource of what? local contact? > remote contact? > These were slight overlooks from me. I'll update it. > > 4) For me it looks like that some column names are too long (like > remote_contact_name) and basically names are not consistent... > Like local_id and local_contact_name... Try to "clean-up" names. > Yes...I will use, as you suggest below: from_id, to_id, from_name, to_name > > 5) Have you looked at Kopete::Message class deeply? > > http://api.kde.org/4.x-api/kdenetwork-apidocs/kopete/libkopete/html/classKopete_1_1Message.html > E.g direction can be also internal. Why did you not stored MessageState > and MessageType? I do not see discussion about it... > > Noted. I will add them. > 6) How will be handled (future) message editation? For this purpose > there is Kopete::Message::id() function which returns unique (I think > per chat session) number. > We will have to discuss this more, I think. We would have to save the sessions. > > 7) I see that you completely removed subject from messages table. But > you did not write reason? Protocols do not use it? Or do you think it is > not needed? > > Btw, more often I'm using column with _id suffix as reference/foreign > key to other table. But do not know if this is something which others > prefer or not too... > > And for handling problem with jabber resource now I got this idea: > > What about storing this? > * protocol > * account > * contact > * from_id > * to_id > * from_name > * to_name > > (from|to)_id will be full protcol *dependent* identifier, so jabber can > store full JID "user@host/resource" and account can represent your > local_id and contact your remote_id. > > But do not know now... Any idea? Make sense? At least it could be needed > to modify it to work with multi user group chat correctly... > Yes this makes sense. > > -- > 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
