Add a way to add more transport Layer

[sbernard31]

In v1.0, LWM2M was only based CoAP(s). In v1.1, LWM2M can be used over CoAP+TCP, CIoT or LoRaWAN In v1.2, LWM2M can be used over MQTT and HTTP (theorically ... https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/520)

So at some time we will need to refactor the code to allow this kind of addition.

This issue is create to discuss/ start thinking about this.

Identified goals :dart: are :

• remove strong californium dependencies. (cf should only be used to implement an endpoints provider)
• being able to add any number of endpoints. (not just 1 coap and 1 coaps)
• being able to add more transport layer.
• being able to have different implementation of same transport layer. (could be different underlying library or just same library with different configuration)

[sbernard31]

For LWM2M v1.1, I created 2 issues :

• #1047
• #1046

[sbernard31]

This task should also aims to reduce dependency to Californium/Scandium project by making possible to implement CoAP or CoAP over DTLS layer based on another library.

[sbernard31]

I started to explore about this at #1220.

[sbernard31]

I created an issue about new Java Module architecture : #1295.

[sbernard31]

A try for the new API : https://github.com/eclipse/leshan/pull/1220#issuecomment-1206271554

[sbernard31]

A cleaner version of the abstraction at server side is available at #1318.

[sbernard31]

A cleaner version of the abstraction at client side is available at #1323 .

[sbernard31]

A version of the abstraction at bootstrap server side is available at #1336

[sbernard31]

First version of transport abstraction layer is now integrated in master.

:dart: Why a transport layer abstraction ?

This transport abstraction layer aims to allow to :

• remove strong californium dependencies. (cf should only be used to implement an endpoints provider)
• being able to add any number of endpoints. (not just 1 coap and 1 coaps)
• being able to add more transport layer.
• being able to have different implementation of same transport layer. (could be different underlying library or just same library with different configuration)

:information_source: What is current state ?

See PRs below are now integrated in master. See their description to have an overview of new API, what is remaining to do and what was removed or broken :**

• https://github.com/eclipse/leshan/pull/1318
• https://github.com/eclipse/leshan/pull/1323
• https://github.com/eclipse/leshan/pull/1336

:pray: How you could help ?

This new Transport Abstraction Layer comes with lot of changes. So we strongly encourage community to give us feedback about API, design and any regressions or missing features.

If you decide to tests master and you face any difficulties to migrate to the new API, do no hesitate to ask ! (by opening a new issue)

:construction_worker: What next ?

The next big step will be to apply a new module design (this will be mainly about project/package renaming):

• https://github.com/eclipse/leshan/issues/1295

Currently we are working on implementing a new transport layer based on something else than californium to test the API and ensure, it fits the need :

• ~https://github.com/eclipse/leshan/issues/1373~ : done

:scream_cat: Any concerns ?

If you have any concerns let us know. If this is about the changes itself : create a new issue our use this one. If this is about the current organization about this changes, there is a dedicated issue : https://github.com/eclipse/leshan/issues/1222

[sbernard31]

Some news about that :

• https://github.com/eclipse-leshan/leshan/issues/1373 is done :heavy_check_mark:
• https://github.com/eclipse-leshan/leshan/pull/1525 is done too :heavy_check_mark:

Next step try to implement :

• https://github.com/eclipse-leshan/leshan/issues/1047#issuecomment-1771317556 (on going :construction:)