[standards-jig] What to do about PubSub
iain.shigeoka at messaginglogic.com
Wed Sep 18 17:07:31 UTC 2002
On 9/17/02 11:12 AM, "DJ Adams" <dj.adams at pobox.com> wrote:
> 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.
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?
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
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
sounding like we want to make interchangeable parts for Ferrari's and
Hyundai's ... Parts that will compromise both final products.
More information about the Standards