Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only register resources for available sensors #31

Open
rosetree opened this issue Jan 4, 2020 · 0 comments
Open

Only register resources for available sensors #31

rosetree opened this issue Jan 4, 2020 · 0 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@rosetree
Copy link
Collaborator

rosetree commented Jan 4, 2020

Discussed with @MatthiasBraeuer offline.

Expected behavior

Only resources for available sensors are registered. /.well-known/core only shows resources that are relevant for this board and only relevant resources are added to the resource directory.

Current behavior

Resources are registered independently of the presence of a sensor. The resources that are registered, are hard coded in saul_coap.c line 44. The registration of the resources takes place in saul_coap.c line 291.

Potential fix

Instead of specifying a resource array, the saul_coap_init() function could start with an empty resource array. It could then iterate over all known saul devices. For every device it could check the device class. If it’s not yet present in the resource array, it could add an entry with a resource path, the context for the handler and resource directory tags (maybe within the context).

  • What will be used as resource path? This doesn’t really matter, as long as the resource is added with useful tags to the directory. Could be a random character or the saul class id. A prefix (like /saul/class/…) might be useful to prevent a crash with another package.

  • What will be used as resource tags? The easiest solution would probably be, to use the RIOT internal class id. But this is not human readable. Also it might change in the future and possibly break apps without RIOT code. A different approach would require some sort of stringification of the class id. Either based on a static and hard coded structure (ugly but fast) or based on some generation of string from the device class enum names.

To address the second question, we could still use a hard-coded array for supported resources. Instead of adding every possible device class as resource, the init function could only add supported resources. These could contain a specified tag for each resource.

@rosetree rosetree added bug Something isn't working enhancement New feature or request labels Jan 4, 2020
rosetree added a commit that referenced this issue Jan 9, 2020
Doesn’t compile currently. Not sure if this might even work, as both
involved structs require constants [0][1].

[0]: https://riot-os.org/api/structcoap__resource__t.html
[1]: https://riot-os.org/api/structgcoap__listener.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant