update: stpeter says it much better than I do, and in fewer words :)
Earlier today I commented on a blog posting by the Gnip team about how they are dropping XMPP support:
Without going into a full blown post about XMPP, our take is that it’s a good model / protocol, with too many scattered implementations which is leaving it in the “immature” bucket. Apache wound up setting the HTTP standard, and an XMPP server equivalent hasn’t taken hold in the marketplace.
My first reaction to this was how they were blending XMPP protocol with customer expectations with XMPP server issues so I left a comment on their blog and that lead to a discussion that went from their blog, to identi.ca across over to Twitter and other places.
While my reading of their post still generates the same questions, one of the big points that settled out of the conversation was that Gnip’s issue was with the ecosystem that surrounds any given XMPP server – not XMPP itself! Still quite a big generalization IMO but a point that I would have to agree with – that’s just the danger of using open-source projects in your business plan.
The problem in a weird way is the success of LAMP (Linux, Apache, Mysql, Python/Perl) and particularly the Apache part of the LAMP stack – it has become a ubiquitous part of any Linux install and there are tons and tons of information and tools available to scale an HTTPd server in any direction you want.
But that totally misses the point – XMPP is not a stateless protocol that was designed for the job it does. Of course it’s going to behave differently and require new skills to manage properly. I remember going thru this exact situation when Apache was the new kid on the block and people were using it because development had stopped on the NTSC HTTPd code base (yes, I am that old.)
Back then it had the same issues and documentation basically meant reading patch and revision histories. As the web grew and businesses grew and things progressed, Apache became very stable and is now almost a no-brainer. Tho I challenge folks to setup an Apache server that does HTTPs, Bosh and can handle a mix of static files and dynamic requests – it’s not really designed to do all that at the same time.
XMPP is at that point now – it’s stable and full of features that are making developers want to include them in their plans but all of the current documentation and use-cases are all XMPP server developer driven. It’s only recently that PubSub has gone from the server dev realm into the systems realm and the stress points are showing :)
That’s what we have been doing at Seesmic – trying to get the final 20% of the classic 80/20 rule implemented with Tigase. It’s also what folks like Jack over at Chesspark are trying with ejabberd and others.
more later about admin tools, documentation and other things that make life in the Ops world easier and that are lacking.
sorry for the rambling post :)
