headstock: XMPP library based on Kamaelia

I’m pleased to announce the release of the first version of headstock, my XMPP implementation using the Kamaelia library. My main motivation behind working on that project rather than using one of the existing libraries was that I wanted to find a challenging project to work with Kamaelia. XMPP seemed challenging enough.
This first release is flagged as beta. Not production ready at all but offers enough so that you can play with it and actually use it for integrating XMPP into your applications. Documentation and tests are badly missing and they will eventually come but for now you’ll have to go through the code. I know this is not attractive but I though it was worth to be released nonetheless. Enjoy.

2 thoughts on “headstock: XMPP library based on Kamaelia”

  1. Hi Sylvain!

    I’ve been looking around the various Python XMPP libraries trying to pick the one most likely to support local-link communications – a mix of XEP-0174 (which also has a bunch of dns discovery magic), and the various Jingle pieces. Do you have any plans in that direction?

    Context – I’m looking at this for smartphone remote controls – http://mail.jabber.org/pipermail/social/2009-August/000547.html etc – and so cutting out network latency is quite attractive of course.

    I don’t mind using public XMPP network as a one time cost, eg. for discovery and authentication… so long as most comms can later happen locally. Ideally I’m looking for a Py library that could eg be bundled inside a Boxee/XBMC plugin, but that might be a bit ambitious 🙂 Without the link-local approach, I’m left playing tricks like using iphone motion sensors to reactivate the XMPP connection when the remote is about to be used…

    Thanks for any thoughts on whether headstrong would be a good fit!

  2. Hi Dan,

    Let’s put aside the language in which the code would be written into for now. Using XMPP with smartphones can be like the greatest idea since the butter knife or a very painful one. Basically the iphone will suck at XMPP. Not from a framework point of view but because you can’t have a daemon process that stays up. Android offers that and there XMPP is just too much fun (notably because the connected socket doesn’t actually consume much energy).

    Now for the purpose you’re suggesting, if you’re going to perform discrete tasks in a single direction (from the remote to the TV). Why even using XMPP? HTTP would seem just as good.

Comments are closed.