On Sunday 11 June 2017 19:25:52 Paulo Lieuthier wrote: > On 11-06-2017 08:28, Pali Rohár wrote> What does the "state" mean? > > Whether the message was really sent or failed to be sent.
Ok. > > 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? > > That's what "sender_id" is supposed to mean. The sender may be the > Kopete user himself. Then how is stored received of message sent by Kopete user? > > 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. > > Could you please expand on that? I'm not following. A real example or > documentation would help me a lot. Every jabber message is sent from pair (local_user_id, local_roster) to pair (remote_user_id, remote_roster). Roster is string identification needed when you connect to your account from multiple clients at same time. E.g. target user is connected from both laptop and mobile and you want to send message to his laptop (not mobile). So it would be nice to be able to also distinguish where were messages sent, but still able to query all messages for particular user. For other protocols there can be session information (e.g. string) to group some messages together. E.g. messages which was sent from one window until both side closed conversation. > > 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. > > All chats with person X (assuming X is a specific contact from a > specific account) would be in a single conversation, so we would > still need only one SQL JOIN. Ok. > >> 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. > > This idendifier wouldn't be provided by the service provider, but > it's internal to Kopete. If it's a 1:1 conversation, it can be the > user email, if it's a group or channel, it can be the group's our > channel's name (or an already existing identification token used in > Kopete). If we don't want to use strings here, for performance > reasons (do you really think that would be a problem?), we have to > come up with a persistent numeric token. It is needed to do tests if strings would be performance problem... I guess it can be as index on strings would be larger as e.g. index on 64bit integer (I hope that storage with maximal 2^64 messages is not a problem...) > > 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). > > Then all the messages between the user and the receiver would form > the conversation, and the identifier could be the receiver's id. > > >> (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. > > That's what I aiming at. I was just commenting on how things have > changed. > > Paulo -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
