The observer implementation and my use case about coap-rs

[osobiehl]

The way observe currently works is a little wonky sometimes. AFAIK it does the following:

• when a request is received, we use coap-lite to intercept the request and handle observation in the crate directly
• updates to a resource are done "automatically" when you put / post to the same resource
• It may be the case that you get a 404 because observe currently "lazily" keeps track of existing resources only AFTER you interact with them. Please look at the tests under src/observer.rs if you want to see how it currently works (you need to send a PUT request first)
• also note that the current observe API can result in your futures not waking up properly if you continue to use the client after observing something (you will have 2 futures polling the same socket if you try to send requests after starting to observe something).

It is pretty difficult to get observe to work like it does in something like libcoap without reworking the server API to define Resources instead of a single handler function. Until then, please look at the tests for observer.rs and see if it works for your use-case

[justinh-xacom]

Many thanks. That explains the behaviour I'm seeing.

Perhaps consider this a feature request: To add a mechanism/option that allows the coap::Server's auto-observe handling to be disabled, in which case observe requests get passed to the handler instead of being internally handled.

For my use case, I could then take responsibility for managing the list of observers based on source IP:Port and token and also take responsibility for pushing notification packets as needed.

[Covertness]

Currently the resource only can be observed after it was created by a PUT request. The resource is updated by sever automatically.
Do you want handle the observe by yourself?

[justinh-xacom]

I think so, yes.
For my scenario, I don't want to force the client to do a PUT before doing a GET+OBS.
Consequently, my program needs to detect the GET+OBS request, generate the resource if it doesn't yet exist, reply to the GET and insert/update the observer list.

I'm also considering a distributed approach, where my resources are stored externally (e.g. Redis). With this in mind, the GET/PUT/POST/DELETE operations when handled by the Server get read/written to Redis. I'd then have a separate process that manages the observer notifications.

[Covertness]

Okey. I will add an option to enable observe message transparent transmission.

[justinh-xacom]

Brilliant. Many thanks.

[Covertness]

The server has a new method: disable_observe_handling. You can find the usage in test case spawn_server_disable_observe.