Riot: Too many coap examples?

[cgundogan]

Hey,

I noticed that we feature 3 different coap implementations in our examples folder. My understanding was that examples exist to showcase RIOT's functionality. Wouldn't one coap example completely suffice to show RIOT's ability to speak coap?

[smlng]

@cgundogan I agree, and with gcoap (#5598) merged, I would see that as RIOTs recommended CoAP implementation to be show cased. Nevertheless, _microcoap_ and others will still be supported, but we should move those examples into the RIOT/applications repo?

[miri64]

I disagree.

My understanding was that examples exist to showcase RIOT's functionality. Wouldn't one coap example completely suffice to show RIOT's ability to speak coap?

So why not show-case that we have 3 (counting libcoap even 4!) working CoAP implementations.

Side-note: Remember that the examples also always should be as minimal as possible to show-case the pure functionality (see #6007 on that note).

In a free operating system alternatives are always good and "natural selection" might show what implementation will be the most dominant.

@cgundogan I agree, and with gcoap (#5598) merged, I would see that as RIOTs recommended CoAP implementation to be show cased. Nevertheless, microcoap and others will still be supported, but we should move those examples into the RIOT/applications repo?

For the same reason I wouldn't state that gcoap should be the recommended CoAP implementation. Also you have to consider that another recommendation we make is to use sock to implement application protocols, so I'm not sure what message it sends if we say one thing and do the other ;-).

Nevertheless, microcoap and others will still be supported, but we should move those examples into the RIOT/applications repo?

If (and only if) we integrate RIOT-OS/applications into our CI process, I would prefer to use it for "more complex" applications than just examples (e.g. CoAP utilizing SAUL, some nice showcase like a cleaned up version of watr.li, etc.).

[cgundogan]

From the point of view of newcomers, I can imagine that choosing between 3 different coap implementations, showcased in the examples folder, is a much harder task. All those examples do not show their full functionality, so it is not even possible to see which of them suits best for a newcomer's task. IMO examples should not exist for the sole purpose of showing how a module is used, but rather what RIOT is able to do.

[OlegHahm]

Same old discussion... I tend to agree with @cgundogan and keep the number of examples small. We might consider to provide one CoAP example where the implementation dependent part is factored out into several source files, e.g. a main.c plus a microcoap.c, a nanocoap.c, a gcoap.c, and a libcoap.c. This might even help to come up with a cleaner interface to all the CoAP implementations.

[miri64]

We might consider to provide one CoAP example where the implementation dependent part is factored out into several source files, e.g. a main.c plus a microcoap.c, a nanocoap.c, a gcoap.c, and a libcoap.c. This might even help to come up with a cleaner interface to all the CoAP implementations.

:+1: Though this might also make the example more complicated than needed.

[miri64]

Same old discussion...

:grin: I was thinking the same

[kb2ma]

Good questions and discussion! Regardless of where the examples are located, I agree that it's important to help users decide which implementation to use.

For gcoap, I maintain a status page that describes its approach. Perhaps @smlng, @kaspar030, and I can put together a page with this sort of information on all three implementations. I see that there already is an Example Applications page on the wiki. To start with, I'll add an entry for gcoap on that page, and move/link the current gcoap status page there.

Regarding gcoap and sock, I have been waiting for the dust to settle to understand it better. With the recently merged PR's, it sounds like now is a good time to take a deeper look to see how it can support gcoap's use case.

[miri64]

For gcoap, I maintain a status page that describes its approach. Perhaps @smlng, @kaspar030, and I can put together a page with this sort of information on all three implementations. I see that there already is an Example Applications page on the wiki. To start with, I'll add an entry for gcoap on that page, and move/link the current gcoap status page there.

@haukepetersen didn't you mention something similar you discussed with @cabo at the t2trg meetup?

[kb2ma]

Just updated the example apps page. Didn't reference/copy my wiki status page since the link to the directory/README accomplishes that purpose.

[OlegHahm]

For gcoap, I maintain a status page that describes its approach

Nice! :+1:

[kaspar030]

How about we remove microcoap? I don't think it'll get much maintanance in the future. yacoap basically took over microcoap's heritage, and nanocoap tries to replace it by just being better.

[cabo]

On 10 Nov 2016, at 12:25, Kaspar Schleiser [email protected] wrote:

How about we remove microcoap? I don't think it'll get much maintanance in the future. yacoap basically took over microcoap's heritage, and nanocoap tries to replace it by just being better.

At some point RIOT should become “opinionated” and offer a default, out-of-the-box implementation of CoAP (of course, people will always be free to implement their own). Removing older, non-maintained (and, frankly, not so good) alternatives might be one step into that direction.

Grüße, Carsten

[nikosft]

I agree, and with gcoap (#5598) merged, I would see that as RIOTs recommended CoAP implementation to be show cased.

gcoap (as well as nanocoap) lacks many features specified by the CoAP RFC (e.g., ACK, separate responses). I cannot understand the excitement about yet another limited coap implementation. Especially when libcoap is out there.

[kb2ma]

Well, I'm excited. :-) Both of these implementations have been around for only a few months. @kaspar030 recently posted his implementation plan, and mine is similar. Let us know of any constructive suggestions or improvements.

[nikosft]

I might moving this discussion out of scope, but what is wrong with libcoap? Why not targeting for making libcoap the "recommended CoAP implementation to be show cased"

[kaspar030]

Especially when libcoap is out there.

Just compare the memory needs.

[smlng]

@nikosft I agree with @kaspar030, libcoap wasn't written with embedded systems in mind. I personally use libcoap a lot, but thats on the Linux side; e.g. on my RPi based 6LBR, to test CoAP server on RIOT bases nodes.

To make libcoap run in RIOT it needs a lot of patching and updating these patches to a new libcoap version is cumbersome. So I'm very happy to see the progress @kb2ma is making with gcoap, and if you miss any feature just let him (or us) know

[miri64]

Regardless we should think about integrating sock into libcoap upstream ;-).

[nikosft]

I can buy the memory argument but the comparison is unfair: on one hand there is libcoap which supports the whole CoAP RFC plus a couple of others, and on the other there is gcoap that supports only a small fraction of the CoAP RFC.

Moreover, libcoap has been developed for years, by a small community and tested by hundreds of users. On the contrary, gcoap has been developed for some months, by a single person (??) and it is tested by a significantly smaller number of users.

My point is that (IMHO) gcoap is far, far, far away for being considered the "recommended CoAP implementation"

[smlng]

You're free to use whatever coap implementation you want with RIOT.

This discussion is not about removing any package support, not for microcoap (for now) and certainly not for libcoap. However, the code base of RIOT is growing rapdily and we cannot ship examples for everything, but there still should be some show-cases on the core features such as coap.

I've never used libcoap with RIOT directly only for testing from a Linux client, if you have some examples where you use libcoap in RIOT please share them with the community!

[kb2ma]

Passionate advocacy makes things happen! If someone wants to leverage the use of LWIP within libcoap with the LWIP wrapper for sock, I think that would be well received here. It would allow for a more direct comparison of resource usage, too.

I respect the work Olaf and the libcoap group have done, but CoAP is important enough to develop independent implementations that are well suited to a particular environment. I also personally really appreciate RIOT's emphasis on detailed documentation, including HOWTOs, and I am trying to do that in gcoap.h.

[nikosft]

I have successfully used libcoap with RIoT and I recently shared an example with dev and users mailing lists. The code is here https://github.com/nikosft/libcoap/tree/master/riot Moreover, the code has been successfully tested on a nucleo board.

[OlegHahm]

@nikosft, not sure I get your point. libcoap has many features, but is of limited used because of its memory footprint - I'm not aware of a configuration where it would fit on a class 1 device, are you? gcoap has less features, but has a reasonable memory footprint and a design particularly designed to be used with GNRC (which I, as one of GNRC's co-designers obviously support).

Hence, IMO it's perfectly valid to put efforts into supporting both libraries. But maybe I miss your argument.

[kaspar030]

gcoap has less features, but has a reasonable memory footprint and a design particularly designed to be used with GNRC (which I, as one of GNRC's co-designers obviously support).

Let's not forget nanocoap, which is used by gcoap as "backend" for parsing/creating CoAP packets, but can be used stand-alone. It will make it possible to have a coap client/server on class 0 devices, with RAM and ROM left for applications, if gnrc can be left out.

[OlegHahm]

So, as a conclusion of this discussion: how about we go with https://github.com/RIOT-OS/RIOT/issues/6038#issuecomment-257820162 for now and after we gathered some experience with all the available CoAP implementations, we may decide to recommend one of them?

[kaspar030]

how about we go with #6038 (comment) for now

I think all the necessary ifdef magic in both main.c and Makefile seems not very appealing.

[OlegHahm]

I would try to put as much as possible into the Makefile and go with various .c files.

[OlegHahm]

Did we reach a consensus here?

[kb2ma]

@OlegHahm, I appreciate the concerns behind the issue of too many examples. On my side, I have focused my limited time on adding features to gcoap rather than work on this single example with multiple implementations. The reimplementation on sock rather than GNRC is targeted for the 2017.01 release. I'm also just a few days from opening a WIP PR for Observe.

[OlegHahm]

I'm also just a few days from opening a WIP PR for Observe.

Cool! Looking forward to this.

[cgundogan]

I am exceedingly delighted that my initial discomfort about the number of coap examples led to the long, but fruitful discussion. Re-evaluating the current state, we still have 3 coap related examples in our examples directory: gcoap, nanocoap_server and microcoap_server.

@kaspar030 I looked at the nanocoap_server app. IMO there's nothing RIOT-related in this example that might be important to highlight. Such kind of examples should rather go into the official nanocoap repo [1].

Looking at the microcoap example .. it has the impression on me of being highly convoluted and IMO such examples keep new folks away rather than attract them.

[1] https://github.com/kaspar030/sock/tree/master/nanocoap

[aabadie]

Ok, I missed this one before writing on the ML.

Here is one proposition (roughly copy-pasted from the initial mail):
IMHO, that would be great to only have one example that shows all the CoAP related features provided by RIOT. And for this, gcoap is, I think, the best candidate since it provides server and client features, OBSERVE requests and a shell.

6100 proposed to directly remove the microcoap based example, which I think is not a good solution. I would rather move it to the tests directory and do the same for the nanocoap_server example. Then this would ensure that RIOT remains compatible with microcoap and nanocoap without having too many CoAP examples. Maybe a reference to this tests application could be added in the gcoap example README.

In the end, the change could be to:

• move examples/nanocoap_server to tests/pkg_nanocoap
• move examples/microcoap_server to tests/pkg_microcoap
• update gcoap examples by adding the resources defined in the actual nanocoap_server example (like GET riot/board and riot/mcu)

[kb2ma]

@aabadie, no technical concerns on your proposals for the gcoap example. However, rather than add /riot/value, we could add PUT capability to the existing /cli/stats resource, which would avoid some duplication in what the example demonstrates. It also would allow the user to zero out the value for /cli/stats, which is useful in the context of the example.

[aabadie]

7599 implements my suggestion above.

[aabadie]

Since #7599 is now merged, are you ok to close this one ? (we now have 2 different coap examples instead of 3)

[kaspar030]

one coap example completely suffice to show RIOT's ability to speak coap?

In the CoAP breakout session at Summit '17 we've decided to keep both nanocoap and gcoap as first-class CoAP API's, merging them as much as possible, keeping one for memory and code optimized stuff and the other for higher-level higher-convenience development. Thus it makes sense to keep both examples.

I'll close, feel free to reopen if you disagree.