What if PubSub had come first? (i.e. JEP-0060)

Peter St. Andre asks: "What if every user's Jabber ID were a PubSub node?" (Note: Jabber = XMPP instant messaging).

Well, as I've often said, if "Jabber PubSub" had been JEP-0001 instead of being defined in the much later JEP-0060, many of the other Jabber protocols would never have been created or would be very, very different in the current form. The reality is that many protocols, such as presence, chat, etc. are simply special cases of the more general case defined by Publish/Subscribe. Many other protocols can be easily viewed as simply extensions to a core publish/subscribe system.

If you look at the history of protocols, you'll see that over time, we typically go through a period of protocol proliferation followed by convergence. The proliferation represents experimentation with various ideas while the convergence comes when we finally agree on common 'best" approaches to solving problems. So, back in the 70's and 80's there were lots of different protocols for "messaging" -- the simple problem of sending data from one machine to another. In the 80's and early 90's, we saw a proliferation of "request-response" protocols -- many of which were washed away by HTTP. I think that in the coming years, we're going to see continued proliferation followed by convergence of protocols whose underlying pattern can be described as "Publish/Subscribe." (i.e. a request which gets multiple responses over a period of time.)

As JEP-0060 PubSub becomes more commonly and widely implemented, I am confident that we'll see many more people asking "What if?" questions like Peter's. We'll also see people asking: "Why do we have this protocol when we could just use JEP-0060 PubSub instead?"

Time will tell...

Having opened the subject of Jabber, I've got the excuse to say that I think it is really wonderful that Sun has recently released an implementation of their XMPP/Jabber server. They call it "Sun Java System Instant Messaging" and say:

Sun Java System Instant Messaging provides a standards-based, real-time communication and collaboration application as well as a platform for presence-based application development. It delivers presence information and extended, real-time messaging capabilities, including instant messaging, conferences, alerts, news, polls, and file transfers. As both an application and a platform, it provides the reliability and availability expected by end users and the security necessary to protect privacy and information, and to meet regulatory requirements.

But, do they implement JEP-0060?

bob wyman

Comments

[Zbigniew Lukasiak]

I believe Pub/Sub unifies Push and Pull technologies, as you have the advantages of pushing the information when you want and the advantage of getting only the information you want. It is thus a natural convergence point for both.

[Lance Robinson]

It would be very useful if the XMPP message coming from PubSub would include not only the pubsub subscription name, but also the specific search term that was matched.

[Trejkaz]

I think it would have been quite clean if PubSub had come before the presence stanza. Presence is really, again, just another use case of publish/subscribe.

[Nikolas 'Atrus' Coukouma]

The server configuration guide [1] mentions

sysTopicsAdd.acl - Ability to manage Instant Messaging news channels

The user guide for the IM client mentions:
Administering and managing news channels
Assigning news channel access levels to end users
Assigning end users to news channels (subscribing)
Creating new news channels
Deleting messages from news channels
Deleting news channels
Posting messages in news channels
Removing end users from news channels

Their language seems strange, but I think it can be mapped to JEP 0060:
news channel = node
post = publish
some of the other stuff sounds like node configurations

If they're not using JEP 0060, they should be ;)

[1] http://docs.sun.com/source/817-4113-10/IdenAdm.html
[2] http://docs.sun.com/source/817-4113-10/CstAdm.html