Symas Blog

Today I finished writing a series of patches to enhance LDAP support in Ekiga, the Gnome SIP/VOIP client. Generally I don’t pay much attention to client-side issues; my focus here at Symas tends to be on the server. And for the most part I’ve been ignoring the whole voice-chat/telephony arena because it just didn’t interest me before. But all of a sudden it’s important to me now, and my experience over the past few days pointed out a few areas we really overlooked in the past, things we will need to improve.

There’s a long story leading up to this; I’ll try to spare the details but I blame Ubuntu - it all started on my return trip home from the Ubuntu Developers’ Summit in Prague this past May. At the airport in Amsterdam, while waiting for my flight connection back to Los Angeles, I met a girl. She’s from Asia; she was flying out on her first trip to the U.S.A. We got to chatting while waiting the couple hours for the flight, and one thing led to another… We wound up spending most of the summer together, but she was only on a 3 month visa and eventually had to return home. At the end of September she left, but not before we’d added a webcam to her laptop and tested to make sure that it worked with Skype on her WindowsXP system. Here’s where our current story begins…

30-some hours later she was on the ground, back in her homeland, and we were chatting on Skype. It was a bit laggy but with just audio it was pretty clear. Then we switched on video and boom, the connection died. We repeated a few times but it happened consistently. For whatever reason, we were just not going to get a video chat going. I figured it may be bandwidth limitations, but there were no user controls in the Skype app for selecting video framerate, quality, resolution, etc. It was just “on” or “off” and in this case, “off” was the only setting that worked. Quite annoying.

This moment of aggravation hit several of my hot buttons. Skype is not just a closed-source proprietary app, it also uses a proprietary protocol. There’s no way for normal users to get any helpful diagnostics out of it when things don’t work. And there’s no incentive for the Skype staff to give you helpful information in their tech support channels, because most of it is their IP that you just Don’t Need to Know. But as a software developer, some of the principles I live by are:

1. in software, nothing is impossible
2. when you *can* do something useful, you *should*
3. there’s no excuse for hiding useful information, or impeding users from doing what they need.

Easy-to-use software is great; of course we all want programs that just take one click to get started and do everything we need. But we live in an imperfect world, and things frequently go wrong. If you write software that actively prevents people from seeing what goes wrong, you’re not doing anyone any favors. Your software usability is now binary - it’s either working or not working - and you remove all possibility of graceful degradation or end-user service restoration. Well written software should make the default cases easy of course, but should not preclude anyone from looking under the covers and learning more about the system. Software should allow users to determine their own learning curve, it’s not the software developer’s job to decide the definition of “easy” or draw the line for where “hard” begins. That line falls in a different place for each user, and it does the entire user community a disservice to lump everyone together in the “computerphobe” pigeonhole.

After gnashing my teeth at the stupidity of Skype, I started looking for other chat programs. In my searches I stumbled over Wengophone (OpenWengo, now QuteCom), Gizmo, Empathy, and finally Ekiga. By some strange coincidence, Ekiga 3.00 had just been released that day. It was still only available in source form, but that was fine with me - preferable really. (Binary packages for several platforms are available now…) (OpenWengo was ruled out because their account registration site no longer worked; it wasn’t till much later that I saw that the project had been superseded by QuteCom and by then it wasn’t worth the effort to check it out. Gizmo uses open, standard protocols but it’s closed source. Empathy is a Gnome app like Ekiga, but its UI is still too primitive for my taste.)

I got it built and was soon successfully chatting with the ekiga.net echo test server, (which means, talking to myself through a ~1 second delay line). It would take a few more days to get my friend online… With that task simmering, out of curiosity I decided to see what Ekiga offered in the way of an LDAP AddressBook. What I found was basically unusable. Looking at the code I saw that the config dialog offered a few customization options, but those options were actually being ignored in the Search handler. It was hardcoded to look for two specific LDAP attributes, so if you needed to customize and retrieve something else, you got no results. Needless to say, I couldn’t leave things as they were. I went to the Gnome bug tracker to file a bug report. But looking around, I found that there were already two bugs reported against their LDAP support, so I read them and put in my 2 cents.

One of the other principles I live by is never to complain that something’s wrong unless I know something about making it right. (If you have no idea what’s right, then how do you know it’s wrong?) In the free software world this means I don’t just say “this sucks”, I file a bug report with detailed problem descriptions or with a fix. In this case I saw several things wrong, and it took a series of patches to correct them.

Most of the problems with this code are the same as in a lot of other LDAP clients - hardcoded behaviors, poor use of the API, no support for security… One of my hopes in writing these patches is that they’ll serve as a model for other client implementors. They not only demonstrate how to migrate from very simple, rigidly hardcoded LDAP support to highly configurable support, but also show how to achieve all of these things incrementally. You don’t need to write it all at once, you can test pieces out and get them working in manageable chunks as you go. For me, the increments were determined by how long it took me to grok the Ekiga codebase, and stumbling blocks within the OpenLDAP API.

It turned out to be pretty easy to get most of the desired features working. We could still make things like TLS even easier, but most of these issues don’t require a lot of deep thinking. Things started to bog down when it came to properly implementing SASL authentication. While SASL has been an integral part of the LDAPv3 specification for over 10 years, even today the reality is that few LDAP clients support it. Working on this code, I began to see why…

For starters, the current libldap support requires the client to know too much about the underlying SASL library. Unlike our SSL/TLS support, which programmers can fully utilize using only LDAP APIs, writing the code for LDAP SASL authentication requires both LDAP and Cyrus-SASL specific APIs. (Even though OpenLDAP now supports GnuTLS and MozillaNSS in addition to its longtime OpenSSL support, the specifics are completely hidden inside libldap.)

Furthermore, our recommended SASL Bind API only comes in a synchronous version, while most of the libldap APIs provide both synchronous and asynchronous implementations. The lack of an asynch API here may not have been much of a limitation for simple command-line clients, but most of the interesting clients today are GUI-based and most GUI apps must be event-driven, doing all of their operations asynchronously. It’s extremely unfriendly to lock up somebody’s application window while libldap/SASL are off doing their thing.

It may be too late for this iteration of the Ekiga code, but I’m now taking steps to eliminate these API stumbling blocks in the next OpenLDAP release.

I was going to say there are several happy endings here (I get to make the programs I use behave exactly as they should, we get to improve the usefulness of OpenLDAP software) but of course, this isn’t the end of the story…

This entry was posted by hyc on Friday, October 10th, 2008 at 4:10 pm and is filed under Open Source Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.