Missing module documentation for crypto, rc, CoAP and DHT

[marcelstoer]

https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en-(dev096) is missing documentation for the 3 new modules crypto, rc, and DHT as well as CoAP.

[vowstar]

TODO:@vowstar
Write crypto, rc, DHTLib documents, etc
New usage:
id = 5
status, temp, humi, tempdec, humidec = dht.read( id )
print(dht.read( id ))
Note myself

[vowstar]

DHTLib is OK.
Other is under construction.

[jmattsson]

I should be able to get some time on Monday to document the crypto module. Can/should I edit the wiki directly, or post text here for someone else to merge in?

[vowstar]

@jmattsson You could edit wiki directly, everyone can edit it ;)

[jmattsson]

Okay, I'll do that then. I just didn't want to step on somebody's toes accidentaly.

[jmattsson]

Crypto module docs added. Writing it made me think that the hex & base64 encoding should go in a different module or two, plus get the corresponding decode functions. E.g. hex.encode(str) + hex.decode(str) and base64.encode(str) + base64.decode(str). Thoughts?

[wanghjsg]

Don;t have CoAP doc.

[TerryE]

Writing it made me think that the hex & base64 encoding should go in a different module or two, plus get the corresponding decode functions. E.g. hex.encode(str) + hex.decode(str) and base64.encode(str) + base64.decode(str). Thoughts?

@jmattsson Johny, I am going to do a PR for the fromBase64(). I agree that the separate modules make sense, but do we think that the backwards compatibility break is an issue? Should we leave call hooks in the crypto so old code doesn't break?

[jmattsson]

Yeah backwards compatibility is important, so I'd say leave the crypto entries in there for now. Once we're fully on top of documentation we can look at deprecating it officially. Maybe even add a c_printf() on use to that effect.

Since you're looking at tackling this one, can I suggest another slightly different approach, where we have the modules encode and decode, and then just functions hex, base64 etc on those? I had been thinking about a single module named codec, but that term is so closely tied to audio & video these days that it might be confusing. A single .c file for both encode and decode would be recommended though.

[marcelstoer]

we have the modules encode and decode, and then just functions hex, base64 etc on those? I had been thinking about a single module named codec, but that term is so closely tied to audio & video

I like that but I agree on the naming issue. Other libraries/languages sometimes call those things "endecoder".

[marcelstoer]

The main issue here, "missing documentation", is fixed in or tracked with #774. Closing this one.