| Re: [wakaama-dev] LWM2M 1.1 planning |
|
Hi Scott, I’m also considering LwM2M 1.1 features in wakaama. But I think it will not be a straight forward process. I wanted to add the support of coap+tcp but the current architecture of wakaama is cumbersome and not easy to adapt. So I think the first step before adding 1.1 features would be a re-design of wakaama. Thing is, this is something we, IoTerop, have already done in our commercial product line. We had to reorganize the wakaama source code we were using to add our features including 1.1 ones. We have a clear separation of the various layers:
Objects / LwM2M / Data encoding / CoAP / Security / Transports. This is something we can reproduce in wakaama. Additionally this would come with a new CoAP layer. Having two closer code bases (wakaama and IoTerop’s products) would come with several benefits:
Is it something people would agree with ? Regards, David Navarro From: wakaama-dev-bounces@xxxxxxxxxxx <wakaama-dev-bounces@xxxxxxxxxxx>
On Behalf Of Scott Bertin I’d like to start a discussion planning for adding LWM2M 1.1 features to Wakaama. There are several new features that would be useful in my work, and I would like to start implementing them before too long. First, is there anything that must be finished for LWM2M 1.0 before 1.1 code would be accepted? I’m thinking there needs to be a configuration option for a client to be either 1.0 or 1.1. The server would support either 1.0 or both 1.0 and 1.1. Does anyone see a need for the server to have a configuration supporting only 1.1? I’m
thinking the default configuration would be to support 1.1 with LWM2M_VERSION_1_0 defined to limit it to 1.0 features. For CBOR support, I’m thinking cn-cbor (https://github.com/cabo/cn-cbor) or the modified version (https://github.com/jimsch/cn-cbor) that is used
by COSE-C. The version used by COSE-C would allow COSE-C to be used for OSCORE support without having two sets of CBOR code. I’m already using this in my code, so I’m a bit biased. Regards, Scott
| ||||
