[Standards] RE: [Council] meeting minutes, 2007-04-10
chris.mullins at coversant.net
Thu Apr 12 00:47:13 UTC 2007
[Getting a list of STUN servers]
> Is there any reason it needs to be so complicated?
> If there's not consensus, then maybe pubsub *is*
> a better choice (although still complicated).
I keep thinking a Well-Known PubSub Node is actually quite a bit simpler
than an IQ approach. My thinking is:
1 - The PubSub approach would require no server changes at all - it
would immediately work with eJabberD, JabberD, SoapBox, WildFire, and
XCP. With the custom IQ approach, each server needs to be updated to
explicitly support the XEP, something that may (or may not) ever happen.
I view this as a very large win, and would like to see this used as a
general litmus test for protocol enhancements.
2 - The PubSub approach makes it easier to administer and makes changes
to the list of STUN servers, and (importantly) that the administration
would be identical across server implementations. With the custom IQ
approach, each server is going to take a different approach for
administration: JabberD & eJabberD are going to put it into their config
files, and will require a restart any time the list is changed. SoapBox
would add it to our Management Studio, you're going to add it to your
Web Admin page, and who knows what the XCP guys would do.
3 - With PubSub you have some measure of control over who could see the
list of STUN servers. This security comes for free with PubSub. With the
IQ approach, any security is going to be custom for each server. I can
see this being important.
4 - With PubSub you get Update Notifications for free. With the IQ
approach, it's going to be custom in each server, or not implemented at
5 - With PubSub you can authorize any number of people to publish new
stun servers, how cool is that?
I'm really not sure what complexity you're referring to with PubSub.
It's a pretty simple protocol.
Certainly subscribing to a node is very easy. The actual code (from a
real sample) looks like:
NodeSubscribeRequest subscribe =
new NodeSubscribeRequest(pubsubJID, nodeID, JID.BareJID);
NodeSubscribeResponse nodeResp =
Publishing something is equally easy (from the same sample):
PublishItemRequest publish =
new PublishItemRequest(_pubSubService, _pubSubNodeId);
Getting the contents of that node is no more complex than it would be
// Ask the node for the list of items
GetNodeItemsRequest itemReq =
new GetNodeItemsRequest(pubsubJID, nodeId, subscriptionID);
GetNodeItemsResponse nodeItems =
Processing the node contents is the same regardless of IQ or PubSub.
The only complexity I could see is initially creating the node. This is
also pretty easy to do, so it's just a matter of timing. No different
really than if it were the IQ approach.
More information about the Standards