Re: Chat history progress - GSoC 2017

Paulo Lieuthier <[email protected]> Sun, 11 Jun 2017 14:25:52 -0300
Newsgroups	gmane.comp.kde.devel.kopete
Message-ID	<[email protected]>

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.

> 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.

> 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.

> 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.

>> 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.

> 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
signature.asc (application/pgp-signature, 833 B)