Hi! On Sunday 11 June 2017 12:58:27 Paulo Lieuthier wrote: > Hi all, > > So in this week I've been working on the schema. This is what I came > up with: > > Conversations: > * id > * account > * type (1:1, group, channel) > * entity_identifier (id of contact, group or channel) > > Messages: > * id > * conversation_id > * timestamp > * sender_id (contact id, if available) > * unknown_sender_name (sender name, if id not available, e.g. in irc) > * type (text, event, file, voice clip) > * content (text content or media location) > * importance > * state
What does the "state" mean? Also there is missing indication about direction. How to store message which user of Kopete sent to IRC person? Or how to store message that was sent from user to some chat group? Plus there is missing something like "session" information. E.g. in jabber you can communicate with one person in more one-to-one chats. Every one is identified by jabber roster. Moreover some jabber XEP extension supports some another session identifier which is not bound to roster. What needs to be done easily and very fast is query: Give me all messages which belongs to chats with person X between date1 and date2. > The idea is that from a contact, group or channel in the contact > list, the plugin is able to get a persistent "conversation", and > from that, get all the messages. "entity_identifier" sets the bridge > between a contact (or room, or channel) and a "conversation". Note that some protocols (e.g. skype) has own long-unique-string identifier for persistent "conversation". Such string is not a good idea for indexing or making as foreign key between table. On the other hand, some protocols (icq?) do not have anything like persistent "conversation", there is just information that A sent message to B (and nothing more). > (It's weird that today it doesn't feel natural anymore to simply > focus on contacts instead of conversations, at least UX-wise. AFAIK, > all modern chat services now display conversations in the main > window. Am I alone here?) Basically current UX experience for this year should not affect decision of storage or database schema for something which should be there for a longer time... Storage should be universal and should be usable even if somebody decide to completely rewrite UI or application from scratch. > The messages table is supposed to be agnostic to the protocol and to > the amount of people in the chat. Direct one-to-one and multi-users > chats have the same structure. > > I'm not yet sure how to proper handle multimedia messages, but I > think I should be focusing in text messages for now anyway. Text > messages are stored in HTML in the messages table, but in plain text > in the full-text search table. Kopete basically supports only text messages, so what is needed to store is content of Kopete::Message class. > Any obvious unsoundness in this schema? I'm sure it will have to > improve before the project is complete, but I think this is a good > starting point. > > This next week I'll be working on the storage façade, and probably > send a few more patches regarding Qt5 and KF5 migration! > > Paulo -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
