[standards-jig] What to do about PubSub

DJ Adams dj.adams at pobox.com
Wed Sep 18 18:09:48 UTC 2002


On Wed, Sep 18, 2002 at 10:07:31AM -0700, Iain Shigeoka wrote:
> I agree with the sentiment but have some trouble with the proposal. I don't
> want to be difficult or contrary but... :)

:-)

> 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.

> 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 :-)

> 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. 

> 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 :-)

dj



More information about the Standards mailing list