Closed tobyjaffey closed 10 years ago
Hi Toby,
Do you have an use-case for this ?
In my view, It is the lwm2m_object_t::userData which should contains the lwm2m_context_t if you need it at object level. For instance in the test client test_object.c, it can be a field in prv_instance_t.
I've written bindings for liblwm2m to a Javascript engine. I'm storing a pointer to the Javascript execution context in lwm2m_context_t::userdata. Then, when I get the callback lwm2m_buffer_send callback I'm able to pass the buffer up to Javascript to be handled.
For read/write/exec callbacks, I'm trying to do similar things to allow me to handle the request from Javascript (so I can implement objects in JS). So long as I can find my way from those callbacks up to the lwm2m_context_t that would do.
OK. So do you mind if I integrate only your first change eafe61a ? I would prefer not to modify the object callbacks.
Thanks.
OK. I'll rework my code to pass data through lwm2m_object_t
Reverted the callback change
Modified registration payload to be RFC6690 (application/linkformat)
Hi Toby,
I'm sorry but there are too much changes for a single pull request.
As a general principle, I'd prefer not to modify the test applications except if there are new or modified liblwm2m's API. They are samples. No need for them to have many features.
Regarding the 5683 port, the LWM2M client is actually a CoAP server. In my mind, the LWM2M Client should be binded to 5683.
Regards
Hi Toby,
I just cherry-picked a lot of your changes. Sorry for the merge headache probably waiting for you...
Regards.
Modified callbacks to pass the lwm2m_context_t * back. Added a void * userdata field to the context so that apps can store their own data and get at it from callbacks.