Closed Areontar closed 9 years ago
It's a big change, it's really interesting for decoupling CoAP implementation from the inner LWM2M server, but it have a lot of impact on the user facing Java API. We should try to think hard on how to limit the added complexity of adding a layer of indirection. Anyway I think we all agree we need to make this change, so I suppose we need to start a branch and work all together on it?
It's a big change, it's really interesting for decoupling CoAP implementation from the inner LWM2M server, but it have a lot of impact on the user facing Java API. We should try to think hard on how to limit the added complexity of adding a layer of indirection. Anyway I think we all agree we need to make this change, so I suppose we need to start a branch and work all together on it?
Yes i agree, i was thinking about that on my way to work this morning, that branch would be a good approach. i think its essential that the lib has that feature, but i agree that impact must be minimal.
One more thing that i did not do is have the construction of the bootstrap server be the same as the coapServer, in then the underlining should not be different, only the LWM2M should be
This is a first pass to a coap shim, the idea it to be able to offer a Bring your own coap client to leshan. This is for the server only. The key elements are that there is a new module called connector. This contains the Californium logic. The leshan core contains the needed abstraction to build your own connector. It also no longer import californium, only the connector does.
let me know what you guys think