Pubsub - how do we use it?

Hey guys, I have been reading about Pubsub and have to admit – I am confused. I get the concept but I have no idea how this feature is getting implemented.

Can anymore show/explain this to me in a little better detail?

Hi Travis,

A good explanation of what Pubsub is and how it can be used can be found in url= Journal #18 (2004-06-15)[/url].

Hope that helps,


I think something we are all missing is a concrete example of how to use pubsub with wildfire. I get the concept- its like RSS feeds, but more generic. But can someone give an example? How do I get wildfire to tell me when some RSS feed updates? Can I “publish” a meeting announcement that others can subscribe to? How do I do it?

What it comes down to…at least this is my perception of the situation…

is that pubsub is a really cool and powerful infrastructure piece that could be used to do lot’'s of really nifty stuff.

However, right now, pubsub is still new enough of a spec (and still be hammered out) that very few people are really using it for any real world uses, yet. I’‘ve seen a few cases of it being used ( is using it internally, I believe, and the user tune, mood and location stuff uses it) but those uses aren’'t widespread.

I, (in conjunction with someone else) am working on (in the very early stages of working on) an XMPP bot that publishes weather alerts and information. Right now, its just user multi-user chat rooms and passing individual s around, but the plans are to publish these alerts and such to pubsub nodes…probably using JEP-0127 (CAP over XMPP).

Just one example…and its something that isn’‘t there today because pubsub is still new enough, and this is something that I’‘ve just started working on, so there’‘s still a lot of development work to do before its doing anything close to what I’‘ve described…and add that to the fact that I’‘m really not a programmer/developer, and you’'ve got a slow moving (at this point, at least) project, at best. :confused:


Hi Jay,

Pubsub was added just at the API level of Wildfire but not as a service that you can configure. So, in order to make use of pubsub within Wildfire you’‘d have to write a plugin that uses that API to publish the information, and of course use a client that can subscribe to the information that you’'re publishing.

I’‘m not aware of specific work anyone is doing that takes advantage of Wildfire’‘s pubsub capabilities but I would suspect that once Spark/Smack supports pubsub (or developers start using the url= Smack Extensions[/url]) you’'ll start seeing some concrete examples of how to use this feature.

Hope that helps,


Ah, my understanding is a lot better now.

So my next logical question is: is anyone working on a plugin or a way to configure this service with Wildfire?


There’‘s not too much that should need to be configured on the Wildfire side, although I’'m sure we could come up with some cool things around configuration of nodes, etc. The major next step is support of pubsub in Smack and then Spark. We hope that will come together over the next couple of months.




Another example is using Pubsub for Whiteboarding. If you are interested you may read the mailing list on . I am also looking at Pubsub to use it for a JEP-0127 (CAP over XMPP) implementation. A Java lib and the CAP Cookbook are available at and


So, what are you planning on doing with CAP?

I’‘m curious as well since I’'m planning on doing some stuff with it in the not-too-distant-future.


So, I started to play with pubsub (by hand, at this point) and Im getting stuck.

First, I create a new node:


And I get this back:


Then, I list things:



(I noticed that it went from ‘‘generic/test’’ to ‘’/generic/test’’). Then I subscribe:



Next, I try to publish something:


But I get this error:


This is right from the JEP, so what am I doing wrong? What should I expect to see?

Hey Jay,

First off, welcome to the pubsub world.

Our pubsub service supports collection nodes (i.e. you can have a hierarchy of nodes) and the root node is using an ID of ‘’/’’. So when you create new child nodes whose parent is the root node then the child nodes ID will be modified to start with / just like you noticed. As you can see the result sent by the server after you created the node includes the node attribute. The reason for that is that the PubSub services had to modify the requested nodeID to start with /.

By default nodes are configured to not store their items in the database and to not deliver payloads. These default values may be modified as specified in the JEP. The JEP also specifies that when publishing to a node that are transient (i.e. do not store their items) and that do not deliver payloads then the publish packet MUST NOT include an item.

The idea of the JEP is to cover cases where node subscribers will just want to get notified that something happened to a node but don’'t really care what happened. The example that was discussed in the XMPP list was the one of a door bell. The door bell would be a node and people subscribed to the bell just need to know that someone rang the bell and nothing else.

Your options here are 1) change the node configuration to include payloads or to make its items persistent (you can even change the default node configuration so that new nodes do not have this “problem”) or 2) change your publish packet to not include an item.

Happy pubsub-ing,


– Gato

Thanks Gato, that explained a lot.

From an “enterprise” standpoint, I’‘m hoping to eventually use PubSub and CAP (JEP-0127) to deliver severe weather and AMBER alerts to our employees. It would also be cool to be able to publish alerts for network outages or service interruptions. I haven’'t really thought of many other uses for our organization.

LoL @ “to publish alerts for network outages”, I really love this one

heh… It probably won’'t be something like “Right now is a network outage.” More along the lines of, “From 4pm to 5pm this evening there will be a network outage.”

Hi Jeff,

mainly for weather and linking directly to systems such as e.g. National Weather Service ( ) in the beginning.

But there is more that could be done later. CAP combines alerts with geo information; linking Jabber/XMPP with GoogleMap?. CAP also supports the inclusion of associated digital images and audio. The inclusion of those messages, for example, allows warnings to be broadcast directly to a radio/image viewer. Or maybe using it in a security infrastructure (see )



Let’‘s get together on this…that’‘s very similar to what I’‘m doing, but I’'ve got availability to a more real-time feed of weather information, alerts and such. Unfortunately, I suck at teh programming, so am looking for some people to collaborate with on this.

How about pinging me and we can discuss some possibilities?


and follow on, how does one delete a node? following the example above (and from the jep),

I was able to create a node, subscribe, and publish. Now I want to delete it:



er, I cut and pasted my purge example rather than my delete example (just substiture “delete” for “purge” - the results were the same)…


It looks like the wildfire pubsub implementation v2.6.2 expects to see delete and purge subelements within a pubsub element defined in the namespace “” instead of “”.

It makes sense to have these operations be performed by the owner of a node but JEP60 v1.7 has specified them under “”. It might be that JEP60 is in the process of being updated and wildfire implementation reflects this.