CoAP API and Drivers

Development
1

Hello everyone,

I’m currently looking for ways to make the CoAP API in RIOT more extensible, i.e., to accommodate drivers, both for built-in functionality like OSCORE and possibly user-defined drivers. For that, I’d love your feedback on a potential CoAP API with driver support.

I’m thinking of a design where a driver essentially acts as a message handler between the user-facing API (client/server) and the CoAP stack’s implementation. E.g., such driver handlers could simply apply some per-message “encoding” or “decoding” (like OSCORE does) (approach 1). Another approach (2) would be to allow these handlers to wait for multiple inbound messages, aggregating them into a single message delivered to the user via regular APIs (client/server), similar to what block-wise transfer (i.e., the reassembly part) would require, if implemented using this future driver API. I also believe, it’d be beneficial to enable stacking these drivers, sort of like of like HTTP server middleware (or channel handlers in swift-nio)

What are common features you’d be looking for in a driver implementation? Were there any cases where you wish a driver API would’ve been available?

2

I am not sure if I understand you correctly here.

I may have thought about something in this direction before. The challenge I had with Web of Things was I wanted to have some middleware that takes a struct and parses request against it. And validates them.

So, as I understand you here, you somewhat want to make this easier to implement. Or am I completly wrong?