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(a)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(a)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.