SMCP Updates and Possible Name Change

[Robert Quattlebaum]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello everyone,

As you may have noticed, recently there has been [a lot of updates][1]
to SMCP's `master` branch. There will continue to be a flutter of
activity as I work toward what I hope will be a high-quality 0.07.00
release. If you haven't had a look recently, here is a quick
high-level summary of the recent changes:

* The platform API is now more clearly defined, which should make
porting SMCP to new platforms more straightforward.
* You can now specify installation-specific configuration options
via the `configure` script. ([`6228af0`][2])
* `smcpd`, which had been quite neglected, is starting to see some
love; including new nodes for observing files (useful for exposing
specific files from `procfs` or `sysfs`).
* Fixed IPv6 multicast support
* Support for RFC7390-ish multicast groups. ([`f5fd27f`][3])
* Reintroduction of the "pairing" system, which provides a generic
in-band configurable way to make changes to a resource on one
device immediately update a resource on a different device.
* Countless other miscellaneous updates, fixes, and improvements.

Here is what is left to be done for 0.07.00:

* DTLS Support ([#35][4])
* Improved API Documentation
* Possible Project Rename

There have been a few false-starts to DTLS support in SMCP over the
past few years, but with the recent work in the `feature/dtls` branch
I feel fairly confident that DTLS will be working soon. If you would
like to help with this effort have a look at issue [#35][4]. I
consider DTLS support for `plat-bsd` to be a must-have for the 0.07.00
release.

Another big focus of the 0.07.00 release is trying to achieve the
semblance of API stability. Still a long way away from that goal, but
recent changes have made significant progress toward that end. True
API stability won't be guaranteed until the 1.00.00 release, but the
sooner the API stabilizes the sooner we can hit 1.00.00.

- ---

I'd like to bring everyone's attention to issue [#37][5], which
discusses the possibility of renaming the project, among other things.
For your convenience, here is the text of that issue:

> SMCP is an acronym that originally stood for "**S**imple
> **M**onitoring and **C**ontrol **P**rotocol", and the `smcp`
> codebase was to be the initial implementation of that protocol. The
> idea was that that SMCP would be a light-weight, UDP-based
> machine-to-machine protocol that could run on microcontrollers.
>
> I described the original M2M system in a fair amount of detail in
> [this message from 2010][6] sent to the IETF CoRE mailing list. More
> recent musings on the topic can be found [here][7].
>
> Work on SMCP (both the protocol and the software) started long
> before I learned about CoAP, but after I learned about it I quickly
> began to rewrite the `smcp` codebase to use CoAP instead of the
> original homegrown MEME-over-UDP based protocol. However, not all of
> the original M2M mechanisms I had originally envisioned carried over
> easily to CoAP, and most ended up being removed despite their
> utility. These capabilities are starting to be reintroduced (See the
> [M2M label][8]).
>
> All that aside, I'm throwing around the idea of renaming and
> relaunching the software. This will hopefully generate some
> additional interest and help avoid confusion by removing any
> ambiguity between the CoAP stack and the M2M protocol that uses
> CoAP.
>
> However, in order to rename a project, one needs to have something
> to rename it to. Any ideas?

- -\- Robert Quattlebaum

[1]: https://github.com/darconeous/smcp/issues?utf8=%E2%9C%93&q=milestone%3A0.07.00%20
[2]: https://github.com/darconeous/smcp/pull/30/commits/6228af07fb9b051672a3264fbe5efa200e97c6d4
[3]: https://github.com/darconeous/smcp/pull/30/commits/f5fd27f8a3b68421d6c280f58f5c3965ef3d45b3
[4]: https://github.com/darconeous/smcp/issues/35
[5]: https://github.com/darconeous/smcp/issues/37
[6]: https://www.ietf.org/mail-archive/web/core/current/msg00119.html
[7]: https://gist.github.com/darconeous/fee998ee26260caad1443546e81fe06c
[8]: https://github.com/darconeous/smcp/issues?utf8=%E2%9C%93&q=label%3AM2M%20

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXjecYAAoJEE6OLsxF2Ko6N94H/3fHL27FZyM9ZuIWgL0LUgYT
wjrA4Sh8XO5Id94sSTu/l9U0Zp9vctkPejGnesWvLD4LrW1aPHFNQ5LzX30quwIe
xv8J22Tbuw+vmDISo4QwfcWiPE58NOjCZWNxS6JXOuZSxElvOpWyHA38ho6nJpE9
UsW37rpX+zOGzJ0jR0t+JROsBouvCRQxIUmPABv/eH5ajmVM5xa6y3ILRLpQ1jne
u/1dI36ZeA/WuCPxfutM26Uj67+lGlm42YTwT69TvXxaUQBcNyA5hXaeDV0Q1qdJ
KifhdpyFiugRBUqQGufgitR2gx3RdmBiMQOmvAHOgAEkF93RuWAUkBviGC2QODA=
=FP57
-----END PGP SIGNATURE-----

[Ilya Dmitrichenko]

Robert,

I think renaming and relaunching would be a good idea. Also, would be nice to have an document that gives user some feature comparison vs e.g. mbedOS CoAP/lwM2M stack, and other CoAP stacks, such as one by Eclipse IoT group and Contiki also. There may be new things I am not aware of. Also, comparing to MQTT would also help in terms of marketing. Comparing to AllJoyn would be of interest, and, may be even, Google Weave, if that is now a thing. The are folks still talking a lot about MQTT, although I am kindda surprised about that, may be that is a number one to compare with.

Cheers,
Ilya