15 releases
0.3.0-alpha.1 | Nov 1, 2024 |
---|---|
0.2.0 | Jan 15, 2024 |
0.1.6 | Jan 17, 2024 |
0.1.5 | Feb 7, 2023 |
0.0.1 | Oct 22, 2020 |
#194 in No standard library
2,931 downloads per month
Used in 9 crates
(8 directly)
16KB
109 lines
coap-handler
The coap-handler
crate defines an interface between a CoAP server (that listens for
requests on the network and parses the messages) and request handlers (that process the
requests and creates responses from them).
The interface is generic over message formats by using the coap-message crate, which allows the handler to construct the response right into the send buffer prepared by the server implementation. By separating the request processing and the response phase, a server can be implemented even on network stacks that have only a single network buffer.
Convenience, example and reference implementations are available in the coap-handler-implementations crate.
Known shortcomings of the current interface are:
-
No consideration for asynchronous processing.
-
Handler mutability is a bit iffy -- there's no way yet for the server to express any promise about only running one handler at a time, thus handlers often hold shared references to a
RefCell
that isborrow_mut()
'd (if no other code that can be concurrent with the CoAP server can have access to theT
), ortry_borrow_mut()
'd (and errs back with a 5.03 Max-Age:0 response).Alternatives (where multiple handlers could be built based on a single mutable reference to their data) are being explored.
-
Multiple responses (as, for example, in observations) are not supported.
The main item of this crate is the [Handler] trait. The [Reporting] trait can be implemented in
addition to [Handler] to ease inclusion of the rendered resource in discovery, eg. through
/.well-known/core
as implemented in coap-handler-implementations.
License: MIT OR Apache-2.0
Dependencies
~225KB