[standards-jig] What to do about PubSub

Piers Harding piers at ompa.net
Wed Sep 18 12:16:48 UTC 2002

Can we add to this some thought on how to deal with networking pubsub
components together (a protocol for pubsub components to cooperate in
sharing/channeling pubsub data), or will this fall into one of
 the other categories.

Perhaps there is also some tie back into browse/disco here, so we may
need to define how pubsub intergrates with other JEPS/specifications.


On Tue, Sep 17, 2002 at 07:12:25PM +0100, DJ Adams wrote:
> 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
> facts.
> 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
> DJ
> [1] http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-09-17.html
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list