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

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Tue Jun 8 18:49:43 UTC 2004

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Ralph Meijer
> > 
> > yes. all pub sub servers should be compliant with the 
> specification.  but you shouldn't have to write a pubsub 
> server. a generic one should be sufficient if the 
> specification was sufficient robust and well-defined.
> My opinion is that this JEP should form the basis for 
> creating publish-subscribe applications over Jabber/XMPP. In 
> no way was this document targetted for one specific kind of 
> use, as many have commented on earlier.
> Of course, if you implement a pubsub service, it should be 
> compliant with this JEP. However, this doesn't mean that has 
> to be a complete implementation.
> Again, I can think of, and many have in the past come up 
> with, many different uses of pubsub (in the Jabber universe), 
> and I think we would do the community a big disservice by 
> only catering part of potential users. Let me expand.
> Consider an network of embedded systems, for example in a 
> car. There are several semi-independend subsystems in such a 
> car that can benefit from a publish subscribe distribution 
> system. For example, the dashboard shows speed of the 
> vehicle. But, as the car slows down when coming from the 
> highway, the volume of the car stereo is automatically tuned 
> down, to sustain the same perceptive level. The dashboard can 
> subscribe to a node to which the current speed is 
> occasionally published. So can the stereo.
> Although hierarchies could be useful in this setting, I 
> wouldn't use them, and it would be pretty strange to have to 
> implement that into the pubsub service in your car. Why? It 
> has different requirements to the amount of data transferred 
> and there are constraints to the environment in which it has 
> to run in.
> I'd rather use protocol to discover whether the service I'm 
> talking to has implemented. Throwing a disco#info at the 
> pubsub service's JID could do the trick. We only have to 
> agree on a set of feature vars that specify such optional 
> features as hierarchies. If you only want to implement the 
> very bones stuff, you can, and just don't implement disco whatsoever.
> This is acceptable, because if you are talking to a service 
> that doesn't even do disco, it's not a generic service anyway. 

that would be an acceptable solution but the current JEP would have to rewritten to support it. It would still require that some things (like node notification scheme) be clarified. Clarification of things partially described features is different from using DISCO to do feature discovery. you still have to know exactly how that feature will work when its discovered.

> Node hierarchies and the notification behaviour can be 
> specified in a seperate JEP that builds on JEP-0060, and 
> registers a special feature var for discoing.

notification behaviour is part of the core of any PubSub system.  The jabber communities solution too many problems is: oh let's just create yet another jep to discribe this variation and that intead of fixing the core jep in the first place. That's just bad engineering and this approach to solving problems is doing more harm to the jabber community than good. commercial companies are getting frustrated with JEPs and the JEP process because of the constantly changing nature, tendency to create new JEPs to solve exceptions, etc... We need as a community to create a core set of JEPs, make then clear, concise, and non-ambiguous, and then make firm (non changing) -- perhaps evening making an informational RFC about them. A good example would be MUC, there are very few 100% compatible implementations and several companies have not implemented it because its in too much flux. An RFCified MUC (and its support JEPs) would do a tremendous amount to boost Jabber's influence in the corporate and government worlds.

> > 3) node hierarchy support is indeterminate. How do I know 
> if the server supports node hieracharies?
> Disco

hummm...i didn't think the actual query value was described in the JEP.

> > 4) in item 8.1.9 "Implementations of pubsub that choose to 
> persist items MAY allow entities to request existing items 
> from a node." -- MAY allow??? how does a client determine 
> that without actually trying to get an item from node. Its 
> things like this that are problematic.
> This is something that can be stored in the nodes 
> configuration. Examples are in the JEP. If the node is not 
> persistent, you can't ask for past items. If it is 
> persistent, it should logically also allow you to request 
> existing items. If you mean that, I agree.

the later.

> > 5) in item 8.1.8 "Implementations SHOULD use the Data Forms 
> protocol to accomplish this configuration." Well if I don't 
> use Data Forms then how to you configure options...
> You can also send custom namespaced elements instead. This 
> was requested at design time, and doesn't look like a problem 
> to me. If you don't recognise the custom stuff, you ignore 
> it, like with all Jabber protocols.

different issue. I'm saying the way to configure a pubsub service will be Data Forms. A custom elements is a different issue. You are addressing what the element will be but are ignoring the fact that you can not rely of a method of getting, setting, and deleting those elements because the specifiction used SHOULD instead of MUST. With the user or should there is *no* reliable and consistent way to set the elements.

More information about the Standards mailing list