A discussion started recently on the Jabber social mailing-list about the current state of XMPP support at Facebook. If you don’t remember the idea of a XMPP network for Facebook I’d say it’s rather normal considering they talked about it back in May 2008 and nothing has really happened since then. The discussion has quickly drifted toward the difficulty XMPP knows to really make it big and you can sense some despair within the community.

It seems there are several reasons for this.

First and foremost, XMPP is rather poorly integrated within browsers. Today you have to be part of the browser if you want to succeed. Perhaps the response will come from the rather brilliant lib Strophe. Strophe uses BOSH to connect to XMPP services since Javascript doesn’t offer much access to the low level socket connection object. I hope in the future browsers will offer a built-in XMPP API that can be accessed from Javascript allowing to avoid using BOSH.

Second of all, we need big players to start accepting to let go and start entering Jabber federations so that interoperability actually works. I assume companies have yet to find a way on how they can exercise control over the data they might expose through XMPP whilst finding a way to monetize them.

Third I’d say there is a critical lack of PR around XMPP as an added value to the business. To be honest there is the same issue with AtomPub in my opinion. Both are fantastic technologies but they don’t sell by themselves and I find there is a lack of support from companies to support them. SOAP might have been a crap technology but it was backed up by large businesses that were competing with each other (for the worse one might argue).

Finally, and to me this is the most critical reason, XMPP doesn’t integrate well with the web in general. From the browser side as I suggested above to the fact that it’s rather hard to combine web application with jabber ones. Its definitely doable but requires some careful attention to your architecture. Jack Moffitt argues it’s not XMPP’s fault. It’s quite true as a protocol but I believe it’s not really the right way to invite web developers to push it one step further if you blame them for doing it wrong.

I believe XMPP has tremendous potential but it’s still has some way to go before it finds its place.

I am glad to announce that IronPython 2 is now capable of running my XMPP
Python library: headstock.

.NET has already an excellent XMPP SDK called agsXMPP that is a native
.NET/C# framework. However I’m a Python developers at heart and I had
started quite a while ago writing my own XMPP library in Python using the
most excellent Kamaelia framework (designed for concurrency).

For a while IronPython had severe shortcomings that prevented it running
simple Kamaelia applications. Today I was able to run a simplechat demo
using a vanilla IP2 on Windows with only one single modification to the
logging module (thanks Seo). To be honest I didn’t expect it to go through
:)

The chat demo is simple enough but means more complex examples using XMPP
PubSub will work as well (they are all based on the same framework).

Now this isn’t production ready or anything. For instance the TLS support
is broken (hopefully something easy enough to fix) so you won’t be able to
connect to Google Talk for now.

Moreover I’m not sure the code is that fast considering how I had to
simulate an incremental XML parser atop System.Xml (this allows for a
XML stream to be parsed without requiring the full document or even
fragment to be read first).

This is a great news for me because it means I’ll be able to move ahead
with more work using IronPython 2.

Expert Python Programming by Tarek Ziadé is a great book that I recommend to anyone wishing to explore Python in a professional fashion.

The book covers topics that aren’t usual for Python books, at least to my knowledge, like how to build, package, release, distribute your software using tools that have become de facto standards in the Python community (setuptools, paste, zc.buildout, etc.). The book also gently introduces the reader to distributed version control and test-driven development.

The good

The book has 14 chapters and I really believe chapters 5 to 13 are worth every penny. They focus on the delivery of software from building to distributing through testing and optimizing. There is a little something for everyone there and I agree with the book saying it’s an authoritative reference on the subject. If you want an extensive resource on the process of moving from a personal project to a professional one, these chapters are what you need. Of course these chapters aren’t exhaustive but do offer enough meat to get you going and whet your appetite.

Tarek has a great experience in those fields an it transpires he surely wanted to include more content but that would have probably made the book harder to follow.

The “it depends on who you are and what you’ll be looking for”

I don’t want to say bad as it’s only my own opinion here but, I wasn’t convinced about chapters 1 to 4 nor was I about chapter 14. They deal with mainly advanced Python programming dos and donts: iterators, metaclasses, MRO, design patterns. Sadly, I didn’t feel they belonged to the topic of the book. They are interesting on their own but make the book less tight, as if it had started in one direction and suddenly shifted. That being said, they are useful as a reference and even if they aren’t always crystal clear, they are an enjoyable source of information.

A summary

Writing a book of this nature is hard because it’s large in scope but also in audience. Tarek explains that the book aims at Python developers but that in some instances project managers may find it useful. This is probably true if they were developers at some point. Expert Python Programming is a rich technical book which names isn’t too cocky considering its content.

Not only did I enjoy the book I also brought it to the office as it was immediatly useful to a case I was working on. Recommended.

I’ve been working recently with Adrian Hornsby who’s been interested in using the microblogging example I had setup to demonstrate headstock, amplee and some ideas about microblogging in general. Today Adrian asked me how to add some gelocalization information to a message flowing through the system. It took me just a couple of hours to implement it so that now you can push a message like: GEO text [lat,long] through your IM client. This will tell the demo to add a georss:point element to the generate atom entry which will eventually lead to a Google map to be displayed in the web page mapping the atom entry.

I’ve recently registered to Notifixious home page, a notification platform that integrates XMPP natively. Though the application is not looking as polished as one might hope it already provides interesting features.

Overall I think any work towards better notification system is the right idea. We need better ways to notify people or get notified about relevant piece of information. From a technology’s perspective transport protocols (well at the application’s level) already exist to perform the task of carrying the information, they are namely HTTP and XMPP. However there is still quite a large gap to fill about what to carry exactly. Notifixious doesn’t solve that gap per se but offers at least a good base for playing around with some floating ideas. For instance I’ve introduced today the Notifixious’s crowd to LLUP which has been initiated and carried on for a few years now to answer that specific problem. Perhaps it’ll make it way through.

Update: The guys at Notifixious just posted a message about how PubSub is heavily used by their service.

I’ve just released amplee 0.6.1.
This release is a minor release that fixes a few annoying defects and improves overall performances of the internal of amplee:

• removes many of the usage of the copy.copy function (thanks to Mohanara Gopala Krishnan for his previous help)
• drops the cmemcache module in favor the python-memcached one
• adds a prune(member) method to the indexer API
• extends with a few helpful functions the atompub API
• adds more unit tests
• drops the graph subpackage from the egg distribution (and I will remove it altogether for license issue in the next release)

If you’re using 0.6.0 I would advise to upgrade. The API is fully compatible and you’ll experience a more stable product.

I really wish to thank Mohan for his feedback, patience and will to send patches.

I will release a next version to clean out some remaining issue and than I will move toward amplee 0.7 that’ll support Amara 2.0 and will see some internal refactoring.

I have recently subscribed to the excellent Good Reads network and today I went to it only to see a message saying:

The system is down for maintenance as of 00:51 PDT.
It’ll be back shortly.

That’s okay, I mean it’s not such an essential website in my life that I have to get connected to it. I’ll visit it back. That being said I realised that if you plan on creating the next social network that everyone speaks about [1], make sure that you do your maintenance on a per-time zone basis. It’s cool to wait night in the USA to be the as little disruptive as you can but the rest of the World might not appreciate being put off in such fashion.

Of course scheduling maintenance based on a time zone means your infrastructure is designed to support it. Well, you said you wanted to be the next D.
[1] I don’t believe that’s something Good Reads is after mind you.

I knew Freebase was great but this rules.

I’ve decided to make an official release of a few of my currently most active projects so that it’ll be easier for anyone to try out. So today I’ve released:

• bridge 0.3.6: Simple library for handling XML. This one is just a fix release and won’t break any of your application if you were using it.
• headstock 0.2.0: XMPP library using Kamaelia and bridge. My main focus on this release was the support of PubSub.
• jlib 0.1.0: Python library of PyQt4 widgets to add XMPP to your applications. This one is rather new and still pretty limited but it’s already fun to use.

There you go, neither headstock nor jlib are considered to be production ready but are stable enough in terms of design and implementation so that you may already start playing with them. I hope you’ll have fun.

I’ve been recently working on a library called jlib that providing PyQt4 objects and widgets that can be integrated to a PyQt4 application. In other words jlib is not a new Jabber client but a toolbox to enjoy the benefit of XMPP. The XMPP work is performed by headstock, jlib only glues headstock to PyQt4 through the use of signals/slots.
jlib is not ready yet but here is a preview of a few widgets I’ve already started working on. Ultimately my main interests is in creating a decent toolbox of widgets centered towards XMPP PubSub.