Contacts on Maemo

After the Maemo Summit the details on the address book application and framework in Maemo 5 are finally completely public so I can openly talk about what I worked on during the past year and, even better, I actually have a smartphone that runs this software! (Thanks to Nokia that gave out 300 N900s, but I will talk about this in my next post)

Contacts on the N900

Contact details

As you can see from the screenshots, the Contacts application has everything you would expect from a normal phone address book but it also tightly integrates IM. Your local, Jabber/GTalk and Skype contacts will appear in the same address book and, if you have a friend on multiple IM protocols, you can easily merge all the contacts into a single entity.

My main task has been making the component responsible for the IM part of the address book work properly, this component is an evolution-data-server backend (recently released under LGPL) that acts as a bridge between the Telepathy IM framework and evolution-data-server. See the README file for more details.
Sadly the library on top of evolution-data-server that does the magic contact merging and contains the widgets used on Maemo is not open, but there is some hope for it.

Address book components

At the Maemo Summit I also gave a talk on Telepathy and how it’s used on Maemo, both for messaging/VOIP and for the contacts integration. The slides are available in PDF or in OpenOffice.org format (but for some reason colours look wrong in some recent versions of OpenOffice).

More GList anti-patterns

Ross, your examples are not as bad as something I found in some code I had to fix recently:

GList *list = e_vcard_get_attributes (evcard);

for (list = g_list_first (list);
     list != NULL;
     list = g_list_next (list))
{
         /* Do something */
}

for (list = g_list_first (list);
     list != NULL;
     list = g_list_next (list))
{
         /* Do something else */
         g_object_unref (list->data);
}

g_free (g_list_first (list));

“Surprisingly” it was not working, but at least it was not leaking memory as the return value of e_vcard_get_attributes is not supposed to be freed

Parsing names

In the last weeks I have been asked several times to modify some components I’m working on to add the ability to split a full name in its components (first name, family name, etc.).
It looks like most people have great expectations about this working correctly but they get annoyed when it fails, and you can be sure it will fail. It will fail because it’s impossible to parse a name correctly, for instance:

Full name	First	Middle	Last
Barack Hussein Obama	Barack	Hussein	Obama
Pier Silvio Berlusconi	Pier Silvio		Berlusconi
José Rodríguez Zapatero	José		Rodríguez Zapatero

How can you do this automatically?

This becomes particularly silly if you cannot be sure that the string you are going to parse is actually a full name, for instance don’t try to parse a chat nickname. It’s true that gmail/gtalk uses your full name by default, but this is only a default and it’s true only for gmail.

To cut a long story short, please please please don’t try to parse names. You can see by yourself how hard it is, even if I’m just considering western-style names.
If you still don’t trust me here’s a quote from e-name-western.c, i.e. the file that does name parsing in libebook :

* <Nat> Jamie, do you know anything about name parsing?
* <jwz> Are you going down that rat hole? Bring a flashlight.

On a side note when you are trying to understand why some code is broken you can find some funny commits, like the great EDS purge

Update: I found this “serious” bug in e_name_western_parse .

WebKit GTK on iRex Digital Readers

When I joined Collabora last year I started to work on porting WebKit GTK to a device produced by iRex technologies based on the GNOME mobile stack and with an electonic paper display. My task was to make WebKit usable for the browser that they want to ship with the next version (with Wi-Fi connectivity) of their device, this meant adding missing features, fixing various bugs and adapting WebKit to work well with this kind of devices.

At FOSDEM I willl give a talk on what I did and I will have with me a DR 1000S, so you can play with it (I suspect that most people will follow the talk only because of the nice toy )

An iRex Digital Reader 1000S

SOCKS5 in telepathy-gabble

In the Telepathy framework there is a mechanism, called tubes, for arbitrary data transfer with your IM contacts so you can play games, do collaborative editing, etc. Until now telepathy-gabble (the component that does XMPP) supported only in-band bytestreams, or IBB for short: all the data is sent inside the XMPP stream encoded in base64. The pro of IBB is that you don’t have to worry about NATs or listening on new ports but on the other hand it’s slow and could use too many resources on the server.

In the long term we want to use Jingle also for data transfer and not only for audio/video calls, but in the meantime we needed something better than IBB so Guillaume Desmottes and I started to implement SOCKS5 bytestreams support in telepathy-gabble. With SOCKS5 bytestreams you just send a list of IP addresses, both yours and the ones for possible intermediate proxies, when you want to start a bytestream. The other side tries to connect to the addresses it received and, when it succeeds connecting to one of them, sends the working address back to the initiator. This leads to three possible results: a direct connection, a connection through a proxy (still better than with IBB as you don’t use base64 and the proxy can be a separate machine from the XMPP server) or just fail if no connection is possible.

In XMPP you decide whether to use SOCKS5 or IBB using a negotiation method called stream initiation that allows the choice of a single bytestream method, if it fails you cannot fallback to the slow but safe IBB. Just failing is not acceptable as the applications running fine with just IBB could stop working for somebody, so we decided to extend stream initiation. With our simple extension we can keep compatibility but also be able to try SOCKS5 and, in case of failure, switch to IBB.

With fallback we were able to finally merge the SOCKS5 branch, so now the next two steps are adding support for intermediate proxies (for now we do only direct connections), and add file transfer using the same bytestream mechanisms. Hope to have good news about this soon