Category Archives: Uncategorized

Which XMPP technologies to use?

I’ve been writing a piece of software in order to perform a major upgrade of ZATEMAS, a specialized web app suite I’m a co-author on. Since there is a small community of users on it that might interact better if they had an opportunity to do so, I came to an idea to provide them with an instant messaging client built right into the browser, similar to Facebook Chat, Meebo Bar and Gmail Chat. I’ve picked XMPP as the protocol; better known as Jabber, this is the same protocol Google Talk uses.

Examining various options took a while. I’ve looked at Meebo Bar, and concluded that it doesn’t fit my use case, since I want users to be automatically logged in on a local XMPP server.

I’ve examined several clients. In the process, I’ve learned a bit about BOSH (the standardized method for using XMPP over HTTP), about Apache’s mod_redirect, and a bit about rules for doing cross-domain xmlHttpRequests in Javascript.

The only serious contender for the throne of the best open easily deployable web-based XMPP client is JWChat. This is a venerable old client which creates a popup and behaves much like a typical desktop IM client. This means it was unsuitable; there is no easy way to embed it in a page, yet preserve its state upon page switching.

This is actually the biggest problem I came upon. There seems to be no XMPP client nor library written in Javascript that can trivially handle page switching (which means destroying entire Javascript context); you cannot trivially serialize their state. Which is why I’m proud to announce a custom-made client, Z-XMPP. It’s already available for preview on https://bitbucket.org/ivucica/zxmpp, and will soon be available for preview on ZATEMAS. Its license is currently a custom one, hand-written, and most definitely not satisfying any open source/free software definition. That will change soon, as soon as I pick the right license.

That brings us to the other part of the XMPP stack. Which server to pick? Which BOSH connection manager to pick?

There are, really, two contestants in my arena when it comes to a server. First one is a veteran of XMPP, ejabberd. ejabberd is written in Erlang, and is massively scalable. It’s trivial to install and configure in Debian, and it supports a lot of cool features out of the box. It supports something called “shared rosters”, which basically means you can create groups in people’s contact lists that you, as the admin, can enforce to contain whomever you want. You can force people, for example, to see everyone else working in the company. This is a critical feature for ZATEMAS, just as is so-called “external authentication”. What I’m missing here is: external auth does not support fetching any attribute apart from basic operations with passwords (is it correct? please change it!), and vCard cannot be created from command line, only updated. This means I cannot trivially set people’s real names during an update run.

Obviously, ejabberd has flaws, and I cannot easily update it since Erlang is a language fundamentally different from any other I worked with.

So the second contender is a server I discovered only tonight. It’s Prosody, an extremely lightweight XMPP server written in Lua by a bunch of very friendly folks. I really like the attitude and personal approach the principal author of Prosody has, but that’s not all. Server’s source code looks extremely well organized, the server is quite featureful, and most importantly, it’s written in a language that mere mortals can understand. I’m not a big fan of Lua, but I can read it, and I can update it, especially when it’s so well written as Prosody seems to be.

I’m currently not very familiar with Prosody, but the fact that I managed to set it up very quickly and that it starts up momentarily… well, I think that we can hack a ZATEMAS-based external authentication module into it! Also, I think I might be able to better add my own debug functions, to easily see what I did wrong while developing my client.

Both ejabberd and Prosody come with a BOSH connection manager (the thing that translates HTTP requests into a continuous XMPP stream; a continuous XMPP TCP stream is something you cannot achieve from the web). So why another one?

Well, perhaps you want to log into Google Talk!

Yep, folks, that’s what PunJab allows: have your BOSH-based client log into any XMPP server. I must say I like PunJab; it’s written in Python. Despite that, its internals seem a bit less clear than Prosody’s, yet still manageable. PunJab does its job and does it extremely well.

So there you have it. Perhaps we’ll soon have an opportunity to talk about how to install Z-XMPP instead of just talking about why and how I’m working on an IM service 🙂

Until next time!

Making iPhone calls to Google Talk/XMPP Jingle/XEP-0166 users

If you are looking for an iPhone application to make calls to Google Talk users (and all others who use Jingle extension for XMPP, or XEP-0166), check out Talkonaut. App is currently free on the app store, but I wouldn’t be surprised if that changed; in fact, I’d love it if the developers made extra money by doing so. I’d give back the free version and give a few bucks for the paid version. It’s worth it.

It even contains Jingle-to-SIP conversion; that is, you can use the XMPP connection to establish a SIP connection. SIP is a “more traditional” VOIP protocol, while Jingle is what Google Talk uses.

They also have partnered with many SIP-to-PSTN providers (where PSTN is regular telephony, such as landlines and cellphone), enabling you to make GTalk-to-phone calls for apparently very low prices. At the moment I have no need for such a service, but it might be a good way to pay back for the free app. I’m not getting paid to say all this — as a developer, I can appreciate the numerous hours that went into this project.

What sort of software do I need libre/open-source?

After thinking a bit about what I need open-source, and what I’m capable of implementing but too time constrained, here’s a short list. If I had enough cash and if I didn’t have to study, I’d go now and work on some of these.

Open source Steam

And I don’t mean just a game browser and installer. I mean the full deal: friends, shop CMS, patching, DRM, DLC, ingame overlay. Friends could work with XMPP, and when I think about it, so could everything else. How about login with OpenID, Facebook Connect, XMPP?

Better, modular X11 login manager

I want a login manager where I can easily write a GUI in OpenGL or whatever I want, and just plug it in with the backend code that’ll handle the login itself.

I started writing that, but then I got a Mac.

In-game XMPP overlay

I’m sort of obsessed with in-game overlays, right? But that’s what I want to have: a way to talk to my google-talking buddies from in-game. Steam’s in-game browser is NOT a solution. I’ve tried looking around for something like this; I found some open source code for in-game overlays (Mumble VOIP has one), but nothing simple enough for me to fork and add XMPP code and a simple GUI (perhaps using my GLICT or my company’s AprilUI) to be able to have a proper in-game IM experience.

Well commented and structured code

This is not something I can fix even with a lot of time. I try to structure my code well, but that’s about it.

I’ve been through too much OSS code lately that wasn’t commented well. In fact, I know of one instance where I was studying implementation of in-game overlays, and the already-confusing code didn’t have a single useful comment in it. I’ll do an evil namedrop and mention this was, again, Mumble. I want to make it clear: it’s an excellent project, with lots and lots of cool ideas, well implemented tricks such as positioning audio according to the position in the game the speaker and listener are playing, et cetera. But, simply put, when I looked at the code they had in SVN, I found something I couldn’t put my head around.

Functions and classes were oddly named, not to mention files. Platform-specific code was all mixed up and was not separated; while there were attempts to be modular, separation of platform-specific stuff (and when it’s about in-game overlays, you know it’s VERY platform-specific) was done very clumsily. I couldn’t find where the code initializes system-wide monitoring for the launch of a game, and where the overlay is initialized. I gave up.

But this is what defeats the purpose of open source. Why bother releasing it as FLOSS if people can’t learn anything from it? I wrote a lot of code over the years, but if it isn’t instructional or useful, why would I release it as FLOSS? One goal may be to get it into Debian which has a social contract to ship only free software, but if that’s the entire point, then say so.

Don’t insert assembler blobs without commenting them (oh yes, that too).

What about you?

What do YOU want from open-source community that you can’t find? Or, can you imagine a financing model for developing the above? Tell me your thoughts!

Single Xcode project for iOS and Mac OS X

In Xcode 3.2.4, it’s trivial to create same project for iOS and Mac OS X. Just add a new target into your existing project; if your project is for OS X, then create a new Cocoa Touch Application target. If your project is for iPhone, obviously, craete a new Cocoa Application target. Then do a Get Info on your new target, and choose the appropriate Base SDK. For simplicity, let’s presume you’re adding an OS X target to an iPhone project.

However, after doing this, you’ll quite probably find that despite the choice of Base SDK in your target (you used Get Info on it, didn’t you?), Xcode has locked the target SDK onto whatever your project originally used. That is, now you’ll find it locked onto iPhone, despite switching to the OS X target using the Overview dropdown (in the top left of your Xcode project).

So how do you actually switched the now-locked SDK? Quite simple. Hold the option key while clicking in the Overview box. Instead of only two-entries device list (if you have an iPhone target selected), and then Active Configuration, Active Target, Active Executable and Active Architecture, by holding the option key while clicking on Overview you’ll also find the Active SDKs list. By switching it to the appropriate OS, you’ll be able to compile the application.

Of course, now comes the hard part: actually porting the code to the new platform.
E49PEQSG669E

After MySQL upgrade on OS X, all tables are missing

When upgrading MySQL on OS X (anno domini 2010),  I learned the hard way that the “data” folder containing your databases and tables does not get moved. Look into /usr/local; you will probably have the old mysql-* folder there containing just the “data” folder. /usr/local/mysql is a symlink to the current MySQL installation, so move its data folder elsewhere, and put the old one in there.