I appreciate the great feedback - I was able to get my test stubs going and will begin integrating with my project. I also like the example-rich XEP-0060 spec which quickly clarified the messages.
I have three items that do not seem to follow the spec. It is unclear if is just the spec language, a server bug or a programmer bug
- Although a node is set to not persist items, it seems to persist them anyways.
Here is the node information:
…
…
However, if I run the publisher and publish a few events, then run the client, when the client sends the availability message, the past events are received. I would expect that since the events were sent before the client was started (and that persist items is “0”), that these events would have been purged. Not persiste items is the default state when a node is created but it persisted them.
-
When an owner creates a node, the server automatically subscribes the owner to the node. This is strange since I could not find any discussion in the spec that indicates this would happen. It is also undesirable since after each node is created an unsubscribe request for the newly created node needs to be sent (to prevent the owner from receiving its own messages).
-
One bug which hung me up for a while is when the client was subscribed, the publisher sent an event, the server responded OK but the event did not go through. The reason was the client needed to change its presence state to “available”. Maybe a comment in the spec on the client state would clarify this.
Brett Lindsley
Applications Research Center
Motorola Labs