Comments (4)
I have worked with a lot of different Web API's and must say I like to keep the ResourceHandler as simple as possible and prefer to stick with a simple Handle(Reqeust, Response);
I know the following pattern from other languages. Maybe it can help you a bit with your issue:
// Register like this:
CoAP_CreateResource(HandleWithData);
HandleWithData(Request req, Response res) {
void* pUserData = FindUserData();
CustomHandler(req, res, pUserData);
}
CustomHandler(Request req, Response res, void* pUserData) {
// Implement what you need
}
You would probably need 100 different HandleWithData
functions, or implement some lookup logic inside. Code generation or maybe a macro could help here. But the actual logic must be implemented only once in CustomHandler
.
There might be use cases where a runtime lookup of pUserData
is better and other use cases where static lookups with multiple HandleWithData
like functions is better suited for an application.
I also don't like the idea of handling an additional void pointer in the context of every resource handler. It will increase the memory footprint of the lib and might only be used by a minority of applications (can't really judge this yet, but it's hard to take it back later on). Void pointers might also lead to nasty runtime bugs and are hard to track.
What I like is the context concept of GOs that is also used in the HTTP package: https://golang.org/pkg/context/
Maybe we could have something like this in future. But it would also require some pattern like the one above for actually "fill" the context with user data.
from lobaro-coap.
Heh, I wrote this while a bit sleep deprived last night. I may have somehow forgotten that CoAP_CreateResource()
returns CoAP_Res_t*
which is pretty easy to store in a lookup table... 😅
from lobaro-coap.
I'm still not quite with it it seems. ☕️
Would adding CoAP_Res_t
to CoAP_ResourceHandler_fPtr_t
be okay? I can use that pointer to lookup associated data (assuming the resource pointer itself is immutable)
from lobaro-coap.
CoAP_ResourceHandler_fPtr_t
already returns CoAP_HandlerResult_t
which is used to determine if the Reponse is delayed or not. Actually I would prefer to have this mechanism on the Response object. Leading to CoAP_ResourceHandler_fPtr_t
returning void
But where would you use the return value of CoAP_ResourceHandler_fPtr_t
in your application anyway? The return value is only interpreted inside the lib, or did I missed something?
What we could do is to atatch the CoAP_Res_t*
pointer, which is known to the lib anyway to the request object, to have an alternativ way to identify the resource, beside the URL.
€ ahh I guess thats what you meant anyway. So I prefer adding it to the Request object instead of an extra parameter :)
€2: Which in fact is CoAP_Message_t
and CoAP_Observer_t
. The latter one should be obsolet one day to get rid of a separate method signature for notification handlers.
from lobaro-coap.
Related Issues (20)
- Provide simple setup with only one .a and one .h file
- Optionparser fails if there are no options HOT 1
- Observe in client is not working HOT 3
- CoAP_Res_t.pDescription may be NULL and may hardfault in CoAP_StartNotifyInteractions
- Infinite loop occurred at linked list HOT 1
- Options not optional? HOT 3
- Example code
- Stack smashing due to types length mismatch while calling BGET funcs (amd64 GNU/Linux platform) HOT 1
- TCP support HOT 1
- Should we call coap_mem_release() on pMsg if PayloadMaxSize is exceeded? HOT 1
- CoAP_AllocRespMsg() could return null here HOT 1
- Reserved token length responds with incorrect message ID (confirmable)
- Asynchronous Response (Separate Response) with Lobaro CoAP
- Incorrect #include
- Ignored handler response msg code
- Does this work on windows? HOT 2
- Is there any documentation for this package beside porting guide and examples on lobaro's site? HOT 1
- how to use lobarp-coap act a coap-server
- Does CoAP_CreateMessage have to be called for each message sent?
- Observe and block transfer option append to the request message.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lobaro-coap.