This addresses the issues found by QA in ZEP-1012 and clarify the
documentated behavior as described in ZEP-1859.
Change-Id: I602e5749db7f6f44cf5be449b8e6f0d2ba66b69b
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
NATS is a publisher/subscriber protocol implemented on top of TCP. It
is specified in [1], and this is a sample implementation for Zephyr
using the new IP stack. The API is loosely based off of [2].
With this sample, it's possible to subscribe/unsubscribe to a given
subject, and be notified of changes asynchronously. In order to
conserve resources, the implementation does not keep its own track of
subscribed subjects; that must be performed by the application itself,
so it ignore unknown/undesired subjects.
TLS is not supported yet, although basic auth is. The client will
indicate if it supports username/password if a certain callback is set
in the struct nats. This callback will then be called, and the user
must copy the username/password to the supplied user/pass buffers.
Content might be also published for a given subject.
The sample application lets one observe the subject "led0", and turn it
"on", "off", or "toggle" its value. Changing the value will, if
supported, act on a status LED on the development board. The new
status will be published.
Also worth noting is that most of the networking and GPIO boilerplate
has been shamelessly copied from the IRC bot example. (Curiously, both
protocols are similar.)
[1] http://nats.io/documentation/internals/nats-protocol/
[2] https://github.com/nats-io/go-nats
Jira: ZEP-1012
Change-Id: I204adc61c4c533661eacfb8c28c1c08870debd91
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Leandro Pereira