Crates.io | coap-request |
lib.rs | coap-request |
version | 0.2.0-alpha.2 |
source | src |
created_at | 2023-11-13 17:51:45.163774 |
updated_at | 2024-01-11 13:28:59.891614 |
description | Interface to CoAP requests |
homepage | |
repository | https://codeberg.org/chrysn/coap-request |
max_upload_size | |
id | 1033864 |
size | 9,985 |
The coap-request
crate defines an interface provided by a CoAP client stack towards
applications that can send requests through it.
It is the client side equivalent of the coap-handler crate.
This crate provides a very low-level and generic interface, which is not ideal for every-day "GET me the plain text content of coap://example.com/foo" style requests. The crate coap-request-implementations will fill the gap, just as coap-handler-implementations does for coap-handler.
There boundary of responsibilities for respecting protocol level requirements is not clearly established yet. For example, it is unclear how the application learns special option encoding rules it needs to follow given the transport, or whether other operations on the same stack have concluded their operations w/rt Request-Tag processing.
It is unclear yet whether the async functions should be Send or not (or whether distinct traits are needed to cater for both cases).
The [Request] trait is not suitable for requests for which responses are processed in a pooled fashion (where every response comes in to a single handler to be dissected later); in particular, this trait doesn't lend itself to the implementation of a stateless proxy that uses long encrypted tokens to restore the application state. This may be resolved in a variant of the trait that not only allows later requests to be sent on the same token (as is necessary to orderly close observations) but also to send a family of requests on the same "channel" -- however, that would be a rather nice thing.
License: MIT OR Apache-2.0