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

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jun 4 20:11:26 UTC 2004


 

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Bob Wyman
> Sent: Friday, June 04, 2004 2:05 AM
> To: 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> 
> Boyd Fletcher wrote:
> > NodeIDs and ItemIDs can only contain AlphaNumeric characters.
> 	Why is this constraint useful? Why would it be a 
> requirement? I can see that you are proposing that the "_" 
> character have special meaning, however, why would any other 
> nonAlphaNumeric characters be excluded from use? If you wish 
> to prohibit something, you should clearly define the 
> motivation behind the prohibition.
> 

default separator would be / not _

use of only AlphaNumeric characters simplifies parsing -- i.e. you don't have to encode them. I suppose we could add @ and . to the list, but " and < are definitely out


> > NodeIDs MUST have semantic value in implementations of pubsub.
> > A PubSub service is required to support hierarchical nodes.
> 	It may be that your applications are well served by 

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.

> such requirements, however, the PubSub applications that I'm 
> working on would not be served in any way by such a 
> requirement. Being forced to build hierarchical semantics 
> into nodeIDs would, for us, be simply more work for no benefit. 
> 	You seem to be assuming a topic-based publish/subscribe system.
> Topic-based pubsub systems often are forced to bury meaning 
> in topic names as a means to overcome the limitations on 
> expresibility that are implied by topic-based systems. 
> Unfortunately, the history of this technology includes many, 
> many examples of people producing exceptionally convoluted 
> and complex topic naming hierarchies in an attempt to address 
> the fundamental limits of the topic-based model.

ok then strike the line about the nodeID have semantic meaning.

> 	JEP-0060 should also support content-based pubsub in 
> which nodes have no semantic meaning, they are simply unique 
> identifiers of delivery points. 
> 	Personally, I believe that nodeID's should be opaque 
> strings. If nodes are to have semantic relationships to each 
> other, then these relationships should be explictly stated 
> via metadata -- not buried into nodeId's themselves. 
> 

I don't think that is practical for implementing a hierarchy. However the hierachy does not have to have semantic meaning.



> 		bob wyman
> 
> 
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of 
> Fletcher, Boyd C.
> J9C534
> Sent: Thursday, June 03, 2004 6:27 PM
> To: Jabber protocol discussion list
> Subject: RE: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> 
> 
> 
> You could use the data form spec to specify what the 
> separator for a node is, but I really think it belongs in the 
> core specification for PubSub. My changes to sections 11.3 
> and 11.5 (which both deal with Node
> naming) are:
> 
> 11.3 Node and item id uniqueness
>  NodeIDs and ItemIDs MUST be treated as unique identifiers. 
> NodeIDs and ItemIDs can only contain AlphaNumeric characters. 
> Implementations must have three methods to resolve NodeID and 
> ItemID conflicts that are selectable by the client when 
> creating the first node as part of the create request. These are:
> 
> *	OVERWRITE_ALLOWED=False  - The first publish succeeds, and
> others with the same ID fail. This is default behavior if 
> OVERWRITE_ALLOWED is not specified. 
>    
> <create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="false"
> APPEND="false" />
> 
> *	OVERWRITE_ALLOWED=True - All publishes succeed, each one
> overwriting the older item. 
> 
> <create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="true"
> APPEND="false" />
> 
> *	APPEND - A new node/item is created with monotonically
> increasing number appended to the nodeID/itemID but separated 
> by an underscore. APPEND is false by default. The original 
> node would be:
> 
> <create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="false"
> APPEND="false" /> 
> 
> And the duplicate node would be
> 
> <create node="generic/pgm-mp3-player_1" OVERWRITE_ALLOWED="false"
> APPEND="false" /> Item identifiers MUST be treated as unique 
> within the scope of the node. NodeID + ItemID MUST be unique 
> within a given service, and MUST specify a single published 
> item to a single node..
> 
> 
> 11.5 Handling node hierarchies 
> 
> NodeIDs MUST have semantic value in implementations of 
> pubsub. A PubSub service is required to support hierarchical 
> nodes. Parent NodeIDs are separated from their children by 
> the SEPARATOR attribute to the create node command. There is 
> no limit on the number of children a node may have or on the 
> number of levels of children. The default SEPARATOR is "/".
> 
> Example 91: Node create with separator specified
> 
> <create node="email/bob" OVERWRITE_ALLOWED="false" APPEND="false"
> SEPARATOR="/" >
> 
> So a couple of email messages for the bob node would be:
> 
> <create node="email/bob/232.eml" OVERWRITE_ALLOWED="false"
> APPEND="false" SEPARATOR="/" >
> <create node="email/bob/1958.eml" OVERWRITE_ALLOWED="false"
> APPEND="false" SEPARATOR="/" >
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: standards-jig-bounces at jabber.org
> > [mailto:standards-jig-bounces at jabber.org] On Behalf Of Joe 
> Hildebrand
> > Sent: Thursday, June 03, 2004 6:12 PM
> > To: Jabber protocol discussion list
> > Subject: Re: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> > 
> > 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:
> > 
> >
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 



More information about the Standards mailing list