[Standards-JIG] JEP-0060: Comments on latest draft.
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Fri Jun 25 21:49:38 UTC 2004
> -----Original Message-----
> From: Bob Wyman [mailto:bob at wyman.us]
> Sent: Friday, June 25, 2004 5:29 PM
> To: 'Jabber protocol discussion list'
> Cc: Fletcher, Boyd C. J9C534
> Subject: RE: [Standards-JIG] JEP-0060: Comments on latest draft.
> Boyd Fletcher wrote:
> > [Many things should be MUST that are not now...]
> It is clear that you would like to remove much of the
> flexibility from the current JEP-0060 spec. However, I think
I've NEVER said anything about removing functionality. What I have said was the specification needs to be non-ambiguous and if something is optional there must be a way to discover from the client that it is optional. Making a specification clear and concise does *not* mean you remove functionlity.
> it is also clear that you haven't really done a good job of
> describing why this should be done. It is entirely possible
> that a system as rigid as what you propose may meet *your*
> requirements -- you haven't proven why such rigidity is going
> to meet the requirements of a broader audience. It would be
> helpful if you could do that... (Remember: If you really
> insist that particular options be implemented -- just build
> the server yourself of if purchasing one, make such rigidity
> part of the RFP... Don't use global standards as a way to
> enforce local preferences...)
> It is not reasonable to require, as you suggest we do,
> that all implementations "MUST" support three different
> methods of handling multiple items published with same
> ItemID. Not all servers will be general purpose.
It is either necessary OR what level of support must be discoverable. Otherwise clients cannot depend on the required functionality being there.
> Additionally, there are reasonable handling strategies that
> are not in the list of three that you provide. Thus, in some
> cases, you would require that a server implement features
> that will probably not be used, and in other cases, you've
> made a proposal that doesn't seem to allow the introduction
> of new methods for handling itemID conflicts.
fine then add the new strategies to the specification or let's modify the specification to allow for new methods to be implemented AND discoverable. The current specification does as it is written does nothing but leave the developer hanging in the wind since there is **no** reliable way to know how the server will react to node and item updates. I think at minimum there should be a set of functionality that is required by ALL pubsub servers and item/node updating should be part of that basic functionality.
> Personally, I think it would be much more useful if you
> would focus less on removing flexibility from the
> specification and more on ensuring the removal of ambiguity
> at run-time. For instance, I think it would be much more
I'm not removing functionality. I'm adovacating making the specification clear enough so that a single pubsub server could be used by anyone. What you are advocating is that everyone should write their own pubsub service, I do not believe in that approach. A pubsub service should be generic enough that it can be used for a wide variety of purposes.
> useful if you were to come up with a proposal for how a
> publisher or client would be able to determine, at run-time,
> which strategy would be used by the node to resolve itemID
> conflicts. I.e. should the duplicate itemID handling method
> be returned as a node configuration item? Is there any case
> where it might be desirable to have the method vary between
> subscriptions to the same node? (The answer is "Yes" --
> especially if persistence is
> supported.) Should duplicate handling method be a part of
> subscription options setting? Etc... In any case, worry about
> ambiguity at run-time...
> Don't worry about flexibility in the specification.
if its not in the specification then every pubsub service is unique and custom. If that's the case, then let's just scrap the JEP since all the implementations are essentially proprietary.
> You wrote:
> > When a user subscribes to a node that contains child nodes,
> then any
> > changes to child nodes, their children, or their items that
> > notifications are sent to the subscriber of the parent node.
> There are no "child" nodes in JEP-0060. You should
> probably look at the current draft of JEP-0060 and study the
> discussion of collections in Section 10. Any delivery of
> items to multiple nodes should be done in the context of node
> bob wyman
I don't believe that's a correct statement. There are child nodes in JEP-060 because JEP-60 uses Disco which allows them so might notification problem still exists. From JEP-060 (latest version)
8.1.11 Discover nodes
A service MAY implement some kind of pubsub browsing mechanism which enables the user to discover various nodes. The user may then select nodes which he or she is interested in subscribing to. Entities SHOULD use the Service Discovery protocol for node discovery, subject to the recommendations in JEP-0030 regarding large result sets (for which Jabber Search  or some other protocol SHOULD be used). The examples show the protocol for possible results when using Service Discovery on a hierarchical pubsub service.
Example 65. A client discovers all first level nodes
from="pgm at jabber.org"
to="pgm at jabber.org"
name="A place for generic nodes"/>
name="A place for drinks"/>
name="A place for hats"/>
Example 66. A client drills down to second level nodes
from="pgm at jabber.org"
<query xmlns="http://jabber.org/protocol/disco#items" node="generic"/>
to="pgm at jabber.org"
More information about the Standards