Moving CoAP libraries out of tree

Development Networking
1

As previously discussed among maintainers, I want to put forward the proposal to make our CoAP library an external library that could be used by other operating systems and users. The idea was sparked since some collegues from Lobaro said they were interested in using gcoap in the future instead of their own implementation, but are for various reasons not able to switch to RIOT on the lower end.

The idea would be to abstract away the RIOT-related parts that are used by gcoap, move it to a separate repo under the RIOT-OS organization on GitHub. This would of course increase the maintainance burden on our part, but we could potentially win new, non-RIOT-related users and contributors, potentially other CoAP experts.

Another thing to consider, that while not much work in that direction, there is an endevour to completely revamp / rewrite our CoAP API. So maybe the route to go is not to externalize gcoap, but to start completely from scretch with Yet Another CoAP implementation that aims to solve the API problems we have seen in other CoAP implementations (including gcoap).

2

I’m still skeptical if this worth the effort as there is no common API like POSIX that this could use. (And the POSIX compatibility module is a bit too heavy for this endeavour), so in the end you’ll have to maintain a CoAP implementation and an OS-abstraction API.

But if you want to try it go ahead, I would only insist on only moving to the externalized version once it has stabilized to avoid unnecessary churn among existing CoAP / RIOT users.

Maybe an alternative approach would be moving the FreeRTOS compatibility wrappers that currently live in cpu/esp_common to a common place and filling the missing gaps there?