[standards-jig] What to do about PubSub

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Sep 18 18:32:22 UTC 2002

On 9/18/02 11:09 AM, "DJ Adams" <dj.adams at pobox.com> wrote:

> On Wed, Sep 18, 2002 at 10:07:31AM -0700, Iain Shigeoka wrote:
>> First, a question: is this within the context of the current Jabber
>> protocols or JNG?
> The current Jabber protocols. Definitely. I'm (personally) not even intending
> to consider JNG before we have sorted out pubsub, disco/browse et al.  It's
> too much for my poor brain.

Cool.  Just trying to get the context.

>> Second, if the pubsub differences are significant enough that it requires
>> separate specs, can we really reuse that many components? I'm wondering if
>> it wouldn't be better to identify the major pubsub "camps", and then
>> generate a full set of pubsub docs for each camp. If the approaches are
> This in my mind just a formalisation of what's been happening to pubsub
> already. And look where that's got us :-)

:) Well, I think there is one important difference. Right now, everyone is
trying to get one pubsub designed to meet everyone's needs. The flipside
being, people see the pubsub being developed as being the only option and so
feel obligated to fight to get this or that particular feature in it.

If we formalize the fact that there are multiple pubsub protocols, people
will hopefully chose the one that most closely meets their needs (or will
spawn a new pubsub alternative) and each particular pubsub protocol will
move forward.  Of course this is a theory... :)

There are some interop issues with multiple parallel protocols, but I would
hope that things will be solved via open source meritocracy... The best
protocols will be used and widely deployed, the others will die or at least
be marginalized and mostly forgotten.

>> similar enough that we're reusing a significant number of components,
>> wouldn't it be worthwhile to choose a single path and make it "the chosen
>> one" and leave some people a little disgruntled.  Basically, this is
> It's clear (to me, and others) that we cannot have one single path that
> you have to swallow whole (to mix metaphors) to implement pubsub. Different
> people clearly have different angles, aims, and requirements. That's why
> I think the component approach is a good one to take.

I agree that one path seems unlikely. I'd prefer not attempting a component
approach though...

>> sounding like we want to make interchangeable parts for Ferrari's and
>> Hyundai's ... Parts that will compromise both final products.
> I could interpret that as you questioning Jabber's general ability to
> mould itself (via discrete namespace-defined features) to any task at
> hand... but I'm sure you don't, so I won't :-)

Actually, I take Jabber's flexibility the opposite way: Jabber's ability to
mould itself via namespaces, would allow multiple full protocols to co-exist
side by side so the need for componentizing things is actually reduced not
increased. The only essential shared component would be bootstrapping each
separate protocol via a unified browse/disco...

I'd propose starting everything separate, then when we see implementations
and actual usage, refactor commonalities into componentized sub-protocols.
Anticipating beforehand what will work, what is universal, coordinating
features and changes between components being used by different groups, and
determining what is worthwhile seems... ambitious.


More information about the Standards mailing list