[Standards-JIG] Proposed Changes to JEP-60 - PubSub

Joe Hildebrand jhildebrand at jabber.com
Thu Jun 3 22:12:09 UTC 2004

Is it possible that some of the tightening could take place using 
JEP-68 registered field names in the node configuration form?

Joe Hildebrand
Denver, CO, USA

On Jun 3, 2004, at 2:16 PM, Fletcher, Boyd C. J9C534 wrote:

>> -----Original Message-----
>> From: standards-jig-bounces at jabber.org
>> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Richard Dobson
>> I think I can see why you are getting so confused, JEP-0060
>> is supposed to be just the building block to build full
>> featured pubsub applications, it doesnt really seem that this
>> JEP is really intended to be used to create a pubsub server,
>> as you say it leaves lots of things as optional which is fine
>> as it is a building block, to be useful for building a pubsub
>> server it might be better if we specify it in its own JEP
>> rather than altering this one a unnecessarly restricting
>> future pubsub applications ontop of this, either we need a
>> new JEP based on JEP-0060 that locks down most of the
>> optionals saying all the options MUST be supported in a
>> pubsub server or pubsub server implementation notes need to
>> be added to a similar effect without altering the rest of the JEP.
> ya'll missing the point. The current JEP is not sufficiently detailed 
> enough to build anything but trivial PubSub applications. the changes 
> I am recommending are not limiting and expland and enhance the pubsub 
> specification so that it can be used as the lower level protocol for 
> an unlimited number and type of PubSub applications. For some reason, 
> many of ya'll believe that tigtening up a specification makes it less 
> flexible, while reality it's the exact opposite. Concise, 
> non-ambiguous, feature complete specifications entice vendors and 
> developers to want to implement the protocol because that can 
> reasonbly expect that anyone who is compliant with the specification 
> will have a certain level of functionality. I have spoken with several 
> of the jabber servers vendors about this and the reason they have been 
> reluctant to implement many of the JEPs is: they constantly changing 
> and they have a high degree of ambiguity.
>> Well you did say the following and I quote:
>>> We are not limiting the functionality of the base protocol. We are
>>> significantly enhancing it by specifying how it behaves in a
>>> predictable, well understood manner. So that clients can implement
>>> User Moods, Headline news, avatars, etc.... WITHOUT having
>> to have a
>>> specific custom PubSub implementation on EVERY server you
>> have an account on.
>> This seems to suggest that you think that a pubsub server
>> based on JEP-0060 needs to understand the higher level
>> protocols to work, when it clearly doesnt if you really are
>> understanding what parts of this relate to implementing a
>> pubsub server.
> absolutely not. I'm saying the that core protocol should be 
> sufficiently robust enough so that a SINGLE pubsub server can be 
> written and the high level protocol is handled completely by the 
> jabber client.
>> Also in what way does this protocol stop you from being able
>> to create higher level protocols based on it? I cant see any
>> real reasons, the only real reasons you have presented all
>> have to do with implementing a pubsub server, not higher
>> level protocols, infact others dont seem to have had any
>> problems creating protocols that work based on JEP-0060 (User
>> moods for example), so your argument that you cant build
>> protocols does not seem valid at all as there is lots of
>> evidence to the contrary.
> the current batch of PubSub "applications" are so trivial, they don't 
> run into the problems I describing, but try implementing something 
> like Whiteboarding (like we are) and you start running into lots of 
> issues with the inadequacies of the spec.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig

More information about the Standards mailing list