-
samedi 11 juillet 2009 à 01:17:05
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.
-
lundi 8 juin 2009 à 00:15:24
GSoC & me #1
It's been two weeks since I started the GSoC on Gajim. I chose to start with the roster versionning so I read the XEP-0237 the first week.
By and large, it's clear. I just regret that some points are not enough clear. By example when the server is sending us an iq without a query, it means that it will send us roster pushs to prevent us the changes between the version we have and the server one. But this iq doesn't let us to know if we have the last version and if we will receive roster pushs.
Another problem: when we must receive roster pushs, we have no idea on when excactly we received the last one. So we can't wait until we get the last to continue the connection procedure... For now I made the choice to consider the response iq (with or without query) at the roster request as enough to continue the connection procedure. The XEP says : ‘This specification is specifically designed to allow for a wide range of implementation choices’. So we have no other choice than to decide ourselves when some points are not covered.
Thanks to Matthew Wild and his jabber server written in Lua, called Prosody, I did some tests immediately in the Gajim XML console. I had a better understanding of the XEP after that.
With my mentor Asterix, we decided on a first draft about the way of storing the roster in the client side. Thats how I take one's first steps with sqlite and the Gajim configuration system (I knew that only with the Advanced Configuration Editor (ACE for friends)).
It's not inevitably permanent but that's how i do for now. I am storing the roster version key of each account in the Gajim configuration file (~/.gajim/config). Then i have a table which will store the different rosters inputs (the account jid key, the contact jid key, the name we gave to him, the subscription to the presence and the primary key on the first two fields) and the belonging to the group of each contact (the account jid key, the contact jid key, the group name and a primay key on those 3 fields).
For now the management of the version number is working wonderfully (it is sending well and updating it when there is some changes). I manage roster pushs too (as well at the table level that contains the roster inputs than for the groups).
The next big thing to do will be the management of the response iq when the roster is asking for it. I already found the place I will deal with and I have an idea on how to do it. Now I only have to do it (but it will have to wait until my exam week is finished (and it's starting today)).
-
jeudi 14 mai 2009 à 23:18:27
Google Summer of Code 2009
Hi English-speaking people. I have been selected to participate at the Google Summer of Code 2009. My mentoring organization is PSF, the project is Gajim and my mentor is Asterix (he can be found on the official Gajim room).
It is the first time that Gajim is not mentored by XSF because Peter Saint-Andre^W^WXSF decided not to participate this year. Despite this, there are twelve students that will work on XMPP this summer. So, I am one of them.
Let me introduce Gajim to you. Gajim is an instant messaging client for the XMPP protocol, written in Python and PyGTK. Year after year Gajim earns new features but it's still missing two very important which are very useful when you use your account with several clients and/or several computers and when you have a big roster. So you have chat logs in several places and that becomes a problem when you want to do a search. And when you have a lot of contacts, you have to wait for the server to send the full contact list, so you may have to wait until one minute before you can do something if your roster is very big. That is why I'm intending to develop server-side history and roster versioning for Gajim.
Gajim is no more my main XMPP client. For now it is jabber.el. So, why the hell do I work on Gajim? There are two reasons:
- I have used Gajim for several months. Despite the fact that I no more use it, it's always the XMPP client that I recommand to new users.
- I reported several bugs (some on the BTS, others directly to Jim++ and/or to Asterix). I have organized a bug squashing party. And I also submited some patchs. (yeah, I have my name in the THANKS /o)
For those reasons, I think I am well situated for this. It is also an occasion for me to be involved a little more in a free software project which is not from me. Furthermore, Gajim is migrating to Mercurial. It is been a while I want to migrate my own projects from Subversion to Mercurial, to take advantage of a decentralized VCS, so it is the occasion for me to test Mercurial on a real project.
About the schedule, I plan to develop roster versioning from May, 23rd, to June, 17th and server-side history from June, 18th, to August, 17th.
To finish, I want to thank my mentor, Asterix, which will have to support me during three months. I also want to thank PSF to take Gajim under one's wing for this GSoC. So, thanks Asterix and PSF!