a pythonic walk on jabber’s pubsub

In the previous post, i wrote about the tool i’m using to work with XMPP PubSub.
Now instead of the GUI, we will use the base APIs to create a node hierarchy directly from a python script. The hierarchy will have collection and leaf nodes, mirroring an initial “model” a -recursive- list structure. An example model can looks like the following:

hierarchy = [
             (COLLECTION,"collection1",[
                      (COLLECTION,"collection1.1",[]),
                      (LEAF,"node1.1"),
                      (LEAF,"node1.2")
                   ]),
             (LEAF,"node1"),
             (LEAF,"node2"),
             (COLLECTION,"collection2",[
                      (LEAF,"node2.1")
                 ]),
             (COLLECTION,"collection3",[
                      (LEAF,"node3.1"),
                      (LEAF,"node3.2"),
                      (LEAF,"node3.3")
                  ]),
             ]

The pubsub api of x60br is coded following the twisted asynchronous way: most of the methods perform a IQ call to the server and then return a Deferred, whitout blocking the caller. Then the calling code should register their own callbacks on that deferred to be executed when the response/error becomes available.
The API is still far for complete or stable… but enough to play with it. You can check the epydoc’s generated API Documentation.

In this example, to create the node hierarchy, the main function iterate over the list of tuples, creating the appropriated nodes, and returns a Deferred that will be fired when all responses where received from the server.

def add_nodes(ps,nodes,parent_collection = None):
    #ps is the pubsub service
    if nodes == []: #nothing to do
        return defer.succeed(None)

    #array of pending responses from the server
    #used to fire a callback when all request have been fulfilled
    pending = [] 

    for node in nodes:
        print "Creating node ", node[1]
        if node[0] is LEAF:
            d = ps.create_leaf_node(node[1], parent_collection)
            d.addErrback(log_err,node[1])
            pending.append(d)
        else:
            d = defer.Deferred()
            d_collection = ps.create_collection_node(node[1], parent_collection)
            def create_childs(parent_node,parent_cb,childs):
                d_childs = add_nodes(ps,childs,parent_node)
                #when all childs have been created, fire the completion
                #of the parent's defer
                d_childs.chainDeferred(parent_cb)

            #after the collection node is created, create all children
            d_collection.addCallback(create_childs,d,node[2])
            d_collection.addErrback(d.errback)
            d.addErrback(log_err,node[1])
            pending.append(d)
    return defer.DeferredList(pending,fireOnOneErrback=1, consumeErrors=1)

The full source code for the example is in http://svn.berlios.de/svnroot/repos/x60br/trunk/samples/hierarchy_creation.py

The code is simple, although if you aren’t used to Twisted, it may seems more complex than what really is.
The deferred d_collection is used for collection nodes, after receiving the confirmation that a collection node was created, we make a recursive call to create all the children of that collection.

This simple example creates nodes using the default configuration assigned by the server , but you can also specify configuration fields at creation time, or change the configuration after the creation of the node.

Managing a Jabber PubSub service

Probably you already know many excellent choices for a Jabber(XMPP) client. However most of these clients focus on one specific aspect of XMPP, the most commonly used one: Instant Messaging. But XMPP has a much broader range of possible applications. Already suggested examples of such applications are atom publishing, social websites, shared whiteboards, as system integration middleware, to name only some of them.

However, using Jabber as middleware platform has a little initial drawback for the newcomer compared to most traditional, heavyweight approaches like JMS or JBI: the administration and configuration of many of the services availables are specified as in-band messages to those services. Whitout proper support on the client side, getting started on using those services can be a little confusing, having to read all the appropriate XEPs (XMPP Extensions) and doing all the work by yourself. Note that I’m not blaming that approach.., when you get used to that, you can easily manage your XMPP deployment from whiting you application, and all using a unified, simple technology. Probably this limited support for some of the XEPs is due to the large number of such specifications, some of then pretty recent and still evolving.

Even when the IM clients are implementing more and more extensions, i think that there is room for tools targeting specifically the administrationof the services offered by the server, rather than the usage of them. Something more close to a developer’s tool than a user’s application. And precisely because of the in-band configuration of some of the extensions, implement such a tool is feasible, and in a server-agnostic way .

Some weeks ago, while working with the Publish-Subscribe service (defined in XEP-0060), i found myself doing some not-very-productive activities. During the early development stages of my project, while testing the prototype implementation, i was creating, deleting and configuring nodes by writing raw stanzas at the PSI console.. that isn’t the “computer programmer guy” way, is it?

This is why i started the X60 Browser, a very simple, graphical application that let me do what i was needing: browse and manage the pub sub service from a node owner perspective.

The tool is licensed ad GPL, and currently it will help you in:

• Creating , configuring and deleting pubsub nodes
• Managing node subscriptions
• Managing node affiliations

The sources includes a Python API to use those comands, but there are almost no documentation on that yet.. mmm.. good subject for a next post.