El Tramo | Google Summer Of Code

Google Summer of Code 2012

2012-04-25T00:00:00+02:00

It’s that time of year again: Google announced which students they are going to sponsor for contributing to open source projects. This year, we have the pleasure of welcoming 3 students at Swift, who will be working on some very exciting projects.

This summer, you’ll see the following new faces hanging around the Swift room:

Cătălin Badea will finally bring us the long awaited “Conversation History” support, using the newly minted Message Archive Management XEP
Mateusz Piękos will be adding shared whiteboarding functionality
Yoann Blein is going to implement screen sharing using Jingle

Since Kevin and I could only mentor Cătălin and Mateusz, and we really wanted to have Yoann join us as well, we decided to bring in some extra help this year. Tobias, who not only has participated in GSoC 4 times as a student, but also is a top Swift contributor, and authored practically all of the Swift Jingle code during GSoC last year, will be mentoring Yoann in the screen sharing project.

As you can see: great times ahead!

Experimental File Transfer support hits Swift

2011-09-25T00:00:00+02:00

It’s been a busy summer for Tobias Markmann, one of the XMPP Standards Foundation’s 2011 Google Summer of Code students. He has been working on implementing File Transfer support for Swift, using the fresh Jingle XMPP protocols. I’m happy to announce that we integrated Tobias’s work as an experimental feature into the main Swift branch, where it will be further developed and brushed off before being enabled in our nightly builds and releases.

For those interested in the nitty gritty protocol details: file transfers are negotiated through the Jingle File Transfer protocol (XEP-0234), using SOCKS5 (XEP-0260) as the main transport, and In-Band Bytestreams (XEP-0261) as fallback. To improve connectivity, we use both the NAT Port Mapping Protocol and the UPnP Internet Gateway Device protocols to allow connections through most firewalls, and SOCKS5 relaying proxies in case all else fails.

The new feature has been tested for interoperability against (slightly modified) development versions of both Pidgin and Gajim, which, together with the Pidgin-based Adium, cover a large XMPP user base. After both clients update their protocols to track the newly published Draft specification versions, all 3 should be able to exchange files seamlessly.

What still remains to be done is lots of testing (both internal testing, user testing, reliability testing, and interop testing), bugfixing, and some refactoring here and there to clean up some of the code (which already is in very good shape). Our end goal is to reach a rock solid implementation, with a near guarantee that file exchange will always work (which experience teaches us is far from trivial).

To conclude, we’ld like to thank Tobias for contributing this great new feature to Swift, for providing valuable protocol feedback to the XSF, and for laying the foundation to other exciting Jingle-based features (including voice/video conferencing).

Summer of Swift Code 2011

2011-04-26T00:00:00+02:00

Yesterday, Google announced the 1116 students that were accepted for this year’s edition of the Google Summer of Code, 5 of which will be working with the XMPP Standards Foundation. We’re very happy to welcome both Tobias Markmann and Vlad Voicu, who will be working full-time on Swift this summer, implementing file transfer support and conversation history respectively.

We have to mention that these weren’t the only proposals we received. Most of the proposals we received this year were of good quality: we suspect that the teaser tasks we put up for potential students made it possible for both the students and us to get an idea up front of what should be expected. However, based on experience from previous years, we decided we should only accept 2 students, to ensure that we could give our full attention to making all projects successful (including fast integration into a Swift release). We’re convinced that both Vlad and Tobias will live up to their expectations, and implement some of the most requested Swift features today!

Mimicking Jaiku with Psi

2008-05-02T00:00:00+02:00

The day before yesterday, Peter Saint-Andre sent out a couple of Jaiku invites to all Jabber Google Summer of Code students and their mentors, including me. Never having looked at microblogging before, I toyed around with it a bit, and it quickly reminded me that I still had something on my Psi wish-list for a while now: a flat, live log of all Jabber events in your network. Since I had a long weekend, I quickly coded up a prototype, and hooked it into Psi.

The result looks a bit like this:

If you know Jaiku, you’ll probably notice that this looks very similar to the Jaiku web interface. Besides status messages, there are all kinds of (extended) presence events from your contacts, such as the currently playing tune or his/her current mood. Groupchat (`channel' in Jaiku) and directed messages are interleaved with the events, and get a hyperlink which, when clicked, opens up the corresponding groupchat or chat dialog. This type of event log allows you to have a good overview of everything that is happening in your Jabber network. And if your log gets cluttered with groupchat events, you can always disable groupchat events (or any other type of event) at the top of the dialog, with a more compact log as a result. Finally, just as with the Jaiku Jabber bot, you can quickly reply to the last event from a certain user at the bottom of the dialog.

When will this prototype be production-ready, you ask? Well, I’m actually not planning to invest any more time in it in the near future. The reason is that Aleksey Palazchenko (aka AlekSi) will create a brand new history system for Psi for his Google Summer of Code project. I'm pretty sure his new history system will enable us to get a global live history of events, together with filtering based on type. And if we still need some extra functionality, we could always create a plugin.

Improving Psi's roster

2008-05-01T00:00:00+02:00

For a while now, Psi users have been requesting several changes and additions to the roster (or `contact list‘). These requests include grouping contacts into meta-contacts, nested roster groups, and displaying user avatars in the roster. We have been postponing all these changes to the roster as much as possible, because none of us wanted to touch the roster code, for reasons I’ll explain below. This year, Psi is fortunate enough to have Adam Czachorowski (aka Gislan), a student from the Google Summer of Code, to work on roster improvements.

So far, the major cause of all Psi developers staying clear from doing substantial roster changes is probably the fact that all roster-related classes are very tightly coupled to each other. This has several consequences:

It's hard to get a good understanding of which piece of code does what, since there is no separation of logic between the different classes, and none of them work without the other one.
The code is very fragile: if you change one tiny piece, you might break something completely different. Moreover, it's hard to tell what you broke, since the functionality is spread out across the different classes.
The code is untestable: Since there is no decent separation of the roster logic (i.e. the structure of the roster) and the roster user interface (i.e. how it is shown), it has been impossible so far to create some form of automated tests for the roster code. Because of the tight coupling between the various classes, it is impossible to test each part of the roster functionality in isolation, making unit testing impossible. Given that the roster is the most central part of the Psi user interface, it is actually unacceptable that we have no form of testing whether it (still) functions correctly.
There can be no reuse of any of the roster code in other parts of the UI (such as the list of participants in the MUC dialog), or even for other IM clients that are based on the back-end of Psi.

Because of these fundamental issues, a complete makeover of the roster code is in order. More specifically, we want to have a clear separation of anything that has to do with UI, and the actual logic of the roster. Additionally, we want the (untestable) UI layer to be as thin as possible, pushing as much down to the logic layer as we can. Finally, we want to achieve a full coverage of the logic layer using only unit tests.

What Gislan will exactly do in his Google Summer of Code project still has to be worked out in detail. He will be responsible for a major part (if not all) of the roster rewrite, and get some new functionality in there as well (since that will be a breeze with the new code). You can follow his progress on his blog, and get more detailed technical information on the project page for his GSoC project.