[standards-jig] What to do about PubSub

DJ Adams dj.adams at pobox.com
Tue Sep 17 18:12:25 UTC 2002

Dear all

This post is a result of a discussion and general agreement during the
new council's first meeting today[1]. 

We all know that the pubsub situation is ridiculous. A ridiculous number
of JEPs. A ridiculous number of ideas as to what pubsub is. A ridiculous 
amount of time and opportunity lost because of the two first ridiculous

What can we do? Pubsub is important (I think most of us agree on that, at
least). Important practically - there are things that people want to do 
today with pubsub but they're hesitating because of the uncertainty, and
important strategically - in many ways, pubsub embodies much of the 
potential that (non-IM) Jabber has to offer. So we need to make it work. 
Our approaches so far haven't really progressed the issue. So here's a
new approach, originally suggested (I think) by Reatmon. 

Step 1: Realise that there are different interpretations of what pubsub
is about, and different goals/aims

Step 2: Analyse the pubsub proposals and break them down into component
parts that are semi-independent of one another

Step 3: Document those components as separate proposals, to become a set
of parts that you can combine with the core pubsub proposal (this can 
also be seen as a component to be defined) to suit the task.

Step 4: Submit each as a separate JEP

Step 5: Move forward and actually start being productive with pubsub.

As one of the council's aims is to clear the backlog of JEPs and tidy the
environment up, focus fell on two major culprits: browse-vs-disco,
and pubsub. The council's focus on the latter encompasses step 1 above.

So that brings us to step 2. I, and other council (and foundation) members
I'm sure, have already got an idea of how the proposals will break down
in component parts. In the spirit of saying something rather than not 
saying something, I'll throw down what I *think* are the different components
(if not just to give you an idea of the granularity in mind):

- core pubsub (subscribe, push)
- event vs payload
- data storage
- topic management
- authorization and query (by publisher)

Perhaps each of these (or components like it will end up having their own
namespace). Perhaps not. Only time will tell.

Ok, as a rule, I tend to glaze over when reading an email longer than one 
complete 'page', so I'll stop here so you can too :-)

thanks for listening

[1] http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-09-17.html

More information about the Standards mailing list