Hi Nathan, I agree that usually sending commands should be a transactional process (with an ACK), but I think PubSub doesn't necessarily prohibit that type of interaction, and we could even integrate XEP-0050 on top of it to deal with things like command discovery and lists. In cases where we would like acknowledgements, we typically have the publisher also subscribed to the same node. We basically handle acknowledgments like call-backs where the agent doing the actuation should publish the updated state of the actuator once it finishes. An interested node (or nodes) can use this as an ACK. This might not be the most efficient way of handling a simple point-to-point actuation, but it has significant advantages in the case where multiple agents control devices since all participating agents essentially see the ACK. The PubSub model also helps deal with timing delays for devices that might have slow reactions or intermittent network connectivity. In many sensor networking cases, the round-trip might take long enough that nodes would want to disconnect, sleep and reconnect in separate sessions to see if the actuation was successful.
As for the broadcast control case, there are many examples (we can go ahead and put a few in the XEP). Think about smart grid applications where a power distributor wants to do load shedding and sends out a broadcast command specifying that all low,medium or high criticality devices shut-off. Other examples could include group actuation of distributed components (window controllers in a building, lights etc). -Anthony > ---------------------------- Original Message ---------------------------- > Subject: Re: [Standards] updated Sensors proposal > From: "Nathan Fritz" <[email protected]> > Date: Wed, May 18, 2011 10:44 am > To: "XMPP Standards" <[email protected]> > -------------------------------------------------------------------------- > > This feedback is obviously very late, but here it is just the same. > The reason that I vetoed this spec is specifically that I think > sending commands over Publish-Subscribe is a misuse of the spec. > Commands generally require error handling and acknowledgement. > Additionally, I don't see the use-case for broadcasting commands to > subscribers in this spec. IQ payloads, XEP-0050, and others handle > sending commands, and given the nature of the examples in the spec, I > think these would be better suited for the "setValue" scenario. > > I encourage you to either provide an example and argument against my > reasons stated or re-submit the spec using a more appropriate method > for setValue. I agree that this has use, but I disagree with the > current form for sending commands. > > I apologize that this feedback is so late. > > -Nathan Fritz
