GSoC & me #2
It's been six weeks since I started the GSoC on Gajim.
For now, I am done with roster versioning. Now I'm going to explain the walkthrough.
The last time, I told you about the tables I'm using. The format of the first table, the one which stores the roster entries, changed a bit. Indeed, before I didn't store the state of the "ask". Here is the final format of the 2 tables:
CREATE TABLE roster_entry
(
account_jid_id INTEGER,
jid_id INTEGER,
name TEXT,
subscription INTEGER,
ask BOOLEAN,
PRIMARY KEY (account_jid_id, jid_id)
);
CREATE TABLE roster_group
(
account_jid_id INTEGER,
jid_id INTEGER,
group_name TEXT,
PRIMARY KEY (account_jid_id, jid_id, group_name)
);
WARNING: when we give None to a text field, sqlite will put the text "none". So we have to convert the None in "". Else when we get back the value of the fields, we have "none" strings instead of None.
I'll never thank Matthew Wild enough for Prosody. His software allowed me to test very well my implementation in Gajim. It has been the occasion for him to put his to a severe test. That's like that I found some bugs in Prosody. Bugs that he corrected as fast as he could. Moreover I advise anyone who wants to implement the roster versioning in a client to use prosody as server to do their tests. The server can be easily installed and is very light.
So the roster versioning is now operational in Prosoddy and Gajim. Moreover Asterix just merged my branch with the trunk. The roster versioning is now accessible to anyone that is using the trunk and a server that manages it (i.e only prosody for now).
Please note too that johnny (reachable on the official chatroom of gajim) who did a big sort of gajim's bugs, found an old feature request. It's the report #3190 in which Liorithiel asked that the roster is stored client side. Then when you turn on Gajim we would see our roster without being forced to be online. This is very pratical when the server is down or when we have some unread messages and we don't want to go online for that few. It's also more pratical to search through a contact's logs.
It was not planed at the beginning but since it has been asked very nicely, I did it. So now we can fully benefit it. Because of that, even if your server don't manage the roster versioning, you can still benefit what I have made. Isn't the life wonderful ?
In the previous post Merwok asked me to explain a bit what is the roster versioning. That's true I didn't give enough explanation. I advise the reading of the introduction of the XEP-0237 that explains it very well. Here is a short résumé: instead of receiving the full roster at each connexion, the server only sends the changes since the last connexion. Thereby the connexion is a lot faster all the more when we have a big roster.
Now i have to implement the XEP-0136. It was sold to me as a vulgar way to store chat logs on the server. And yet it's a lot more than that. This XEP allows to define a true policy for the logs management. We can say by example that we always want that our discussions are stored or they are never stored or that we don't care (it's a big résumé). I'll give more details about the mechanism when i'll start the implementation.
From my complicated calculations, we stand a one in twelve chance of not being able to talk with our contact. Indeed when we start a discussion, there is first a negociation. It must determine if we have to record or not the discussions, based on the policy of both sides. In the case where one of both absolutely wants to record the discussion and the other doesn't want at all, the negotiation fails. The XEP is very clear with that: "The negotiation fails and the parties MUST NOT exchange any messages". I must admit that I can't wait to work on this part of the implementation, go and find out why. :D
Server side, I must work with ejabberd and mod_archive_odbc this time. Indeed we can't absolutely rely to the page listing the XEPs managed by ejabberd. It shows that we must use mod_archive which is totally out of date. mod_archive_odbc is not up to date too but it's better than mod_archive.
In a future post, I'll talk about the social aspect of my gsoc.
Commentaire(s)