[ANSWER] Which LWM2M version Wakaama Client supports?

[rpolitex]

Hi, It's Roman, CTO in the embedded dev team Sinai RnD.

Intro

We have wide plans to use the Wakaama Library as the base for the solution we are creating for our Client. I see several times that people ask questions like "Is Wakaama compliant with LWM2M v.1.1 (or v.1.2)?".

To answer this question we have performed an analysis of the gap between the current Wakaama and LWM2M specification. I'm happy to share our results with the community and receive feedback.

Basics

Some considerations:

• this analysis has a preliminary nature, so mistakes are possible, no guarantees
• we are focused only on the Wakaama Client and do not know anything about the Server/ Bootstrap Server functionality
• Wakaama version under analysis 11662338

How to read the table

The Analysis is formatted as a table. It consists of 2 parts separated by a double vertical border. The first part describes which version of the LWM2M Protocol Wakaama supports (for every LWM2M feature). The second part (see in the comment below) shows the evolution of LWM2M features in different Protocol versions (from the introduction to the current state).

There is a color coding in the table:

• LWM2M ver.1.0 - grey
• LWM2M ver.1.1 - yellow
• LWM2M ver.1.2 - green
• LWM2M ver.1.2.1 - blue
• no support - red

Analysis result

The full table is accessible in Google Spreadsheets

[rpolitex]

Second part of the table

[rpolitex]

@rettichschnidi @mlasch @LukasWoodtli

[LukasWoodtli]

Nice! Thank you for sharing!

[sbernard31]

Probably a detail :sweat_smile:, but about Core Link I understand that :

• Core Link Data Format is introduced in LWM2M v1.0.x. (See : §6.4 Data Formats for Transferring Resource Information) which is used for Register/Update Request and also for Discover Response.
• Core Link Data Type was introduced in LWM2M v1.1.x (See core§Appendix C. Data Types (Normative)) This is a possible data type of LWM2M resource in Object Model. (Not sure but I think it is used in Gateway object :thinking:)

Note that :

• LWM2M v1.2.x also add SenML-ETCH JSON and SenML-ETCH CBOR for Composite Operation. (I don't know this part so much...)
• LWM2M v1.1.x also add Unsigned Integer Data Type. AFAIK, there isn't new Data Type in LWM2M v1.2.x.

[rpolitex]

@sbernard31 Nice! Thanks for the clarification.

I plan to collect all the feedback from the community and then update the table.

[rettichschnidi]

This looks very informative. Thanks a lot!

I am starting to think we should have this kind of information stored close to the source code, and keep it up-to-date. Maybe this a good reason to start introducing some proper dev docs, e.g. a Sphinx based one, have it hosted somewhere?

[sbernard31]

I am starting to think we should have this kind of information stored close to the source code, and keep it up-to-date. Maybe this a good reason to start introducing some proper dev docs, e.g. a Sphinx based one, have it hosted somewhere?

I agree.

At Leshan we put it in wiki :

• https://github.com/eclipse-leshan/leshan/wiki/LWM2M-Supported-features
• https://github.com/eclipse-leshan/leshan/wiki/LWM2M-1.1-supported-features

but this is maybe not so smart because this information is strongly tied to the state of the code, so probably smarter to put in code repository. Same for documentation. (And we did same error in Leshan putting documentation in wiki too :grin:)

[rettichschnidi]

Could we host the rendered documentation somewhere on Eclipse infrastructure? Any experience with this?

[boaks]

I started in Californium also with Wikis. After some time I moved the version specific information into Markdown along with the source in the modules. In some cases I also collect the version specific information history and put that always on the "main", so that it's easier for users to see the changes.

[sbernard31]

Could we host the rendered documentation somewhere on Eclipse infrastructure? Any experience with this?

The simple way is to write your documentation in Markdown in your code repository and so you can use default github markdown rendering , Iike with current README. Personally I recommend this way.

If you want to do more (which will be probably more work and not sure if there is more benefits), you can eventually host your documentation in the Wakaama website ?

• the website : https://eclipse.dev/wakaama/
• the repo of the website : https://github.com/eclipse/wakaama-website

Maybe before to go on that direction, it could make sense to ask some advice to eclipse IT : https://gitlab.eclipse.org/eclipsefdn/helpdesk

[rpolitex]

I think both ways have its own pros and cons.

• wiki: more native integration with GitHub infrastructure (e.g. issues), better rendering, collaborative editing

• MDown: better tie to the code, easier to maintain, keeps doc inside the repo

  Seems wiki may be better for Wakaama users; while MDown is better for Wakaama developers.

Bottom line. I vote for MDown for now, as far as we do not have a lot of external users yet. If/when the situation changes - we may render MDown-based docs to the Wiki or Web-site or whatever.

[rpolitex]

@rettichschnidi I hear advice to not use MDown for Docs. And use the reStructuredText text instead.

Like these articles: https://www.ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/ and https://eli.thegreenplace.net/2017/restructuredtext-vs-markdown-for-technical-documentation/ And this discussion on Reddit

This also makes simpler integration with Sphinx in future.

(Personally, I don't have any experience with reStructuredText.)

[boaks]

That may be a misunderstanding, github renders markdown on viewing via a browser. The README.md is shown, when browsing the "code". Other ".md" may be referenced or rendered by click on them.

The point with the variants and dialects is easy, you need to stick to the parts supported by github ;-). And sure, there are limitations, but on the other side, it's pretty easy and works well.

[sbernard31]

@rpolitex thx for sharing this. :pray:

I thought Github was only able to render markdown. :facepalm:

But Reading : https://www.ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/

Developers prefer it because GitHub supports it, though GitHub supports 9 different markup languages, including Asciidoc and reStructuredText.

So I quickly tested for :

• reStructuredText : https://github.com/sbernard31/leshan/blob/test-markup/test-reStructuredText.rst
• asciidoctor : https://github.com/sbernard31/leshan/blob/test-markup/test-asciidoctor.adoc

And indeed they seem to be (at least partially) supported too :star_struck: .

So I change my recommendation :slightly_smiling_face: :

The simple way is to write your documentation in ~Markdown~ any markup language supported by github in your code repository and so you can use default github ~markdown~ rendering , Iike with current README. Personally I recommend this way.

About markdown, I already faced some limitation (or rendering issue outside of github because of lack of standard), so I can easily imagine that it could have better choice. (but I didn't test it)

[boaks]

I had a first impression for reStructuredText.

There may be others with more sophisticated opinion, but for me it looks very similar to markdown. It comes with a clearer structure, but my impression is tables seems to be not the strength.

One pain with that approach (painting in ASCII) is to recommend to use Chrome instead of Firefox. (At least my Firefox breaks such ASCII paints ;-( ).

[LukasWoodtli]

I vote also for developer documentation in the repo. As for the markup language I'm fine with Markdown or with reStructredText.

[rettichschnidi]

IMHO, Tables are pain in both, reStructuredText as well as in Markdown. However, in Sphinx, it is quite easy to include a .csv/.tsv file as table. I found those quite easy to handle using a regular spreadsheet editor (like LibreOffice).

Going this way would require a hosting for the rendered Sphinx documentation however. Something I think is quite easy to do, and totally worth.

[boaks]

I've collected some asciidoc experience in the past days. For me that's very promising, see mobile-bienenstock-waage (German only).

[LukasWoodtli]

The syntax of asciidoc looks nice. But I would prefer to be able to use a documentation system like Sphinx even if reStructuredText is not my favorite markup language.

[sbernard31]

I didn't know sphinx and I have no idea if asciidoc is better than reStructuredText but just for completeness, it seems there also tooling with asciidoc :

• https://gitlab.eclipse.org/eclipse-wg/asciidoc-wg/asciidoc.org/-/blob/main/awesome-asciidoc.adoc#user-content-publish
• https://pandoc.org/

[LukasWoodtli]

I didn't know sphinx and I have no idea if asciidoc is better than reStructuredText but just for completeness, it seems there also tooling with asciidoc

I don't know about the tooling and ecosystem around asciidoc. But Sphinx is well known by a lot of developers and widely used. See the (incomplete) list of projects using Sphinx in the documentation: Projects using Sphinx. There are also a lot of extensions to Sphinx: tooling, plug-ins, themes...

But I'm not hooked to Sphinx. I can live with other solutions, too. I just feel that Sphinx would be a good solution. I would also not add a lot of tooling from the beginning. We should just start to document things by adding markup files to the repo. But it would be cool if we could use a documentation tool as soon as we have some documentation pages put together.

[LukasWoodtli]

It seems that this discussion here is not directly related to the topic of the issue. I'm going to open a new issue, where we can come to a conclusion.

[sbernard31]

I would also not add a lot of tooling from the beginning. We should just start to document things by adding markup files to the repo.

:+1:

I just feel that Sphinx would be a good solution.

On my side, I think this is up to active committers to decide and I didn't see any veto about using reStructuredText/Sphinx. :slightly_smiling_face:

[LukasWoodtli]

See also #732