here a short and long awaited update on my Google Summer of Code work. I've been finishing the update of libpurple's Entity Capabilities implementation to the latest version and added a bit functionality so that 3rd-party plugins for Pidgin can query for some contact's capabilities or adding capabilities to Pidgin's feature list which they implement. It's been tested and seems to work. Thanks to Arne König for testing all this and giving useful feedback.
During the last weeks I've added TXT record lookup to libpurple's asynchronous DNS lookup system and make libpurple automatically query for Alternate Connection Methods for XMPP. The end user won't notice much of the underlying mechanics but if she/he is behind some firewall with HTTP proxy and the XMPP service administrator has setup the right records and services libpurple will automatically use BOSH to login and everything will be nice.
Onto new business. I've started implementing a HTTP 1.1 stack which is nearly finished. I've already started implementing BOSH which is based on this new HTTP stack. The great thing about it is that I use Safa Sofuoğlu's Google Summer of Code project, which is about improving OpenFire's BOSH support, for testing. So if I implement according the spec and something doesn't work I can directly report the errors, discuss them and get them fixed quite fast. The best of all will be a XMPP server supporting latest version, version 1.6, of BOSH in form of a connection manager part in OpenFire and a client supporting the latest BOSH.
The next week I'll try to get BOSH at least working and do some debugging and cleaning here and there. If I don't get it finished till GSoC deadline I'll finish it later on.
Cheers and happy coding,
Here a long overdue and promised update on my work on libpurple's XMPP protocol plugin.
Currently I'm finishing support for XEP-0115 version 1.5 in the protocol plugin. I've decided to only support latest version of the XEP because it's most secure. However, what does this mean exactly?
Well, former caps worked so you give a version string and so called short names with your presence stanzas. Though shortnames are really obsolete and we already have a registry for features identified by their namespace and the former version of the protocol didn't provide any amount of security. One could tell you that it's Psi or Tkabber and send a whole different feature set and all clients with that version would be associated with the wrong feature set of the poisoned cache.
Version 1.5 doesn't have these flaws. Whether your contact has a client distributing its capabilities using SHA-1 or MD5 hash, both are supported by the future libpurple. Sadly for contacts having clients not supporting caps it will simply mean a bit more disco requests. For contacts using clients supporting latest version everything will go smoothly and as soon as their hash is confirmed by own recalculation it's added to the own cache.
In the end Entity Capabilities pave the way for painless and user-friendly modern instant messaging features like voice and video over IP, using Jingle, and gaming applications. In the end libpurple based clients will soon join the row of Entity Capabilities supporting clients, which currently is already supported by the latest versions of Gajim and Tkabber.
Next on the list after finishing caps support. A little bit of ad-hoc support cleanup and after that a BOSH implementation for libpurple.
Since XMPP is (becomming) the biggest player from all the instant messaging protocols out there, there are a lot Google Summer of Code™ projects in the XMPP field this year. BOSH, the highly discussed dream team for connecting to XMPP from mobile or other limited network environments, is covered by a lot projects this year. My GSoC project is, not only, about adding BOSH support to libpurple, the C instant messaging library which powers desktop clients like Pidgin and Adium and web clients like Meebo. libpurple doesn’t only cover nearly any proprietary instant messaging protocol but also some open protocols like IRC, SILC and of course XMPP. For XMPP, as the (future) major instant messaging protocol, it’s most important that XEPs get implemented, coded and used in real life. There is a huge number of XEPs which aren’t implemented and may never be, who knows. I will implement BOSH from the beginning since there is no codebase in libpurple in the BOSH field and just contacted Safa Sofuoğlu, a GSoC student for the XSF mentoring organization, who updates Openfire’s BOSH implementation. We plan to test our implementations of the two XEPs, XEP-0124 and XEP-0206, against each other since he’ll write a server side implementation and I’m writing a client side implementation.
Our aim is to have not just working and good performing implementation but moreover implementations according to the two XMPP Enhancement Proposals. I’m looking forward to the inter-project collaboration.
Cheers and good luck to all Google Summer of Code™ students,