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

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Mon Jun 7 18:24:20 UTC 2004


 

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Bob Wyman
> Sent: Monday, June 07, 2004 1:01 AM
> To: 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> 
> Fletcher Boyd wrote:
> >use of only AlphaNumeric characters simplifies parsing
>    You have been writing messages that make it sound like 
> you're saying that JEP-0060 is horribly broken. To suggest 
> that one of your top "must be fixed" problems is simply 
> something that "simplifies parsing" doesn't make it sound 
> like the problems are as bad as you have been suggesting...


its worst. as indicated by your need to develop your own pubsub implementation

> 
> >> NodeIDs MUST have semantic value in implementations of pubsub.
> > there is no requirement that the client implement hiearchical nodes.
> > its just that the core server must support them. you don't 
> have to use
> them.
> 	I build a server that provides content-based pubsub 
> services over JEP-0060 and has no use for hierarchical 
> nodeIDs. You are suggesting that my server be *required* to 
> provide support for features that only have meaning in 
> old-style topic-based systems even though they will never be 
> used by my server?
> 

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.

> > ok then strike the line about the nodeID have semantic meaning. ... 
> > However the hierachy does not have to have semantic meaning.
> 	If nodeId's have no semantic meaning then any syntax 
> that makes nodeID's appear hierarchical would be deceptive at 
> the least. If hierarchy means nothing, why bother going to 
> the trouble of supporting it? Is your concern simply one of 
> aesthetics?
> 
> 	It would really help your argument if you could present 
> a clear use-case that demonstrates your need for hierarchical 
> nodeId's. What are you trying to achieve?

in a previous email it was pointed out by someone else that node hierarchies can be handle by service discovery. so the need for having nodes with semantic meaning goes away, however, there are still quite number of issues (see below). And the user of service discovery to handle node enumeration should be more clearly explained in the specification.

from a previous email:

1) No clear, concise, non-ambiguous way to do updates to items and nodes
2) Explanation for notification does not explain how:

   a) Does a change in a child node cause a notification to be sent if the user is subscribed to only the parent node.
   b) Does a change in a parent node cause a notification to be sent if the user is subscribed to only the child node.  Is subscribing to a child node and not the parent even possible?
   c) What are te available options for configuring notification? 
   d) Are notifications sent out when a child node is created or deleted? 
   e) Does subscription of a parent node imply subscription to child node?

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

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.

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







More information about the Standards mailing list