Peter - thanks for sharing this! For background, EnerNOC has used XMPP internally for our enterprise-to-device communications for years now, and we've been driving XMPP specification for OpenADR. To give some context, OpenADR is a complex multi-protocol (HTTP and XMPP) specification and we've purposely limited some of the XMPP features that we use, to maintain a certain level of parity between XMPP and HTTP. Many of the OpenADR alliance members have never used XMPP and we tried to keep things simple to make adoption easier, while still giving some of the immediate benefits over HTTP. Our hope is that we can optimize and take advantage of more XMPP features in future versions of the OpenADR spec as we gain experience. To answer some possible FAQs: - Why not use messages? All OpenADR service operations currently expect a response, and the response contains relevant info. In the future, some operations could possibly be optimized to assume message delivery and a "OK" response by default. - Why not use pub-sub? While some event dispatches could be multicast to many clients (VENs) the spec assumes the event payload can contain unique info per client. So a separate payload must be created for each client. But another possible opportunity for optimization nonetheless. Also, we've purposely limited (but not eliminated) the use of presence for two reasons: - Consumer end nodes (VENs) should not be aware of other VENs, only the VTN (the coordinator/ virtual top node) - a top node with thousands or millions of VENs subscribed to its presence presents a performance issue. Some more context: OpenADR is a "high level" energy communication schema that attempts to avoid "direct load control" e.g. Directly interacting with actuators. OpenADR communicates event information and assumes the VEN (client end point) will decide on discrete actions to perform. Similarly, OpenADR supplies "reports" but no direct sensor access. In this way, I think OpenADR is very complementary to the other XMPP IoT efforts going on right now. Open to any comments and feedback from XMPP experts! Thanks! -Thom Thom Nichols Principal Engineer, Advanced Technology Twitter: @thom_nic | Skype: thom.nichols o: 617.532.8154 | m: 401.323.1813 http://open.enernoc.com EnerNOC - get more from energy On 6/20/13 10:43 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear IOTers,
It has come to my attention that the OpenADR Alliance, which produces technical guidelines for demand-response systems, has released a draft version of their 2.0 specification for public comments. You can find the spec here:
http://www.openadr.org/specification
The primary text of interest is Section 9.3, which defines their use of XMPP.
Comments can be sent to mailto:comments@openadr.org (as I understand it, preferably by the end of next week). I'll be sending my feedback before then, and encourage other folks here to do the same.
Thanks!
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwl4zAAoJEOoGpJErxa2pFjkP/j+J0mAWMqaUaVM0tYw4VRf9 BA0wql2d67tRAd/JB2LmZiW0eKfkHBNXtVhrPvXi4eCqPh7Vcr/2FENt28Rc1AWR rR0PO4I/1etLE5HCbYJSWaWQA9WREAGlPSr12hcXRs82CJdwajWUnQMuUJbx7S4t Yxe+6QVdsmqQBQBv3L0ZFiA0B+iLpqr1BW0RVqLBeaYXSynQ2GiBfsuEWZy7jXIH f3eAfB9qUz1B03BVVwLFUlazGKFkQE1KOFKxsDi9uEymvMHDpXZQSSpHYV35F9GJ 72vzSmmtJ4Gp2wZpg9eaZcrJHjoiBu7i8vnqMK9/9A7U1k58EU7DZjc5wj9pStlV taF9WLYfFcEIY7YjNwozH5yLKySCX/erKyq4CbWUyVXOt/P5XARnye4PXvyzAwQH eUhAzSYFU4Dp/9V8rqVRixP0JdVIPf6FW2ajlKjNasj31EQLyksvsPZgu4r5xsp4 MnqQ3PpAtG+JiB2pI1vN2mMPtCL9DkvACFmlxgJeJ/EU9yxkBmXGIR9aXrnLpD36 cwDK0MYvEUk0gREyA9BaOCKH6CViPgrI+XWy8CSytGi3SB475RkfNApM6YCEKuTR blcRHI4P9Dy4Q3zGcQ5FWXQwdYXmog6+KU0gI97ywox0Wap/wMjszGgWdfjaktJh U9xHZHU5UGVmrgmwIwUO =8WEq -----END PGP SIGNATURE----- _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot
This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.