[standards-jig] JEP-0060 PubSub: 5.2.1 Configure a node

Bob Wyman bob at wyman.us
Wed Mar 26 21:04:09 UTC 2003

Peter Millard wrote:
> It was my initial understanding that the implementation 
> which use this behavior would have a tight coupling between 
> consumer of the p/s and the system itself. IE, the client 
> application would know what config options were present on 
> this system based on it's JID.
	I believe it would be very unfortunate if this assumption were
allowed to significantly influence the design of the PubSub protocol. The
problem is, of course, that this assumption would significantly limit the
generality and thus usefulness of the protocol. Implementors would be forced
to find alternative methods of discovering configuration items prior to node
creation. Whatever those alternative methods are, they would make
duplicative the PubSub specific methods for post-creation determination of
configuration options.  
	Persistence is a good example of a capability that a node creator
would typically need to know about prior to creating a node. As indicated in
JEP-0060, persistence is optional both at the server and node level. Thus,
node creators would need to know whether or not persistence was a valid node
configuration item before they create a node. This is especially important
for someone who wants to create a node that *does not* provide persistence
on a server that *does* support persistence. The node creator will want to
state that the node should be initially created without persistence. I.e.
the creator will want the act of creation/configuration to be atomic. Node
creation should not require a multistep process of 1) Create node, 2)
Discover configuration items, 3) Configure node. The process should be: 1)
Discover configuration items, 2) create/configure node as a single, atomic

		bob wyman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2560 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030326/8b0b0ee6/attachment.bin>

More information about the Standards mailing list