QtCS 2017 CoAP

CoAP Client

Contribution consists of CoAP client
- Supports PUT/GET/POST/DELETE
  - Not yet FETCH/PATCH (RFC 8132)
- Supports Blockwise transfer
- Supports Notification (QCoapReply::notified signal, QCoapClient::cancelObserve())
- Partially supports multicast
  - Sending on multicast works and works for receiving one reply
  - Currently does not work with receiving multiple replies
API is modelled after QNAM but does not use it
- QCoapClient, QCoapRequest, QCoapReply
No DTLS support yet (see network discussion)
API does support IETF-style resource discovery (multicast GET to /.well-known/core)
- QCoapClient::discover, QCoapDiscoveryReply
- API needs a little work:
  - signal and parameters
  - discover() should be able to send on both IPv4 and v6 multicast, without the user hardcoding anything
  - building of query parameters (QUrlQuery?)
Add a method to QCoapClient and QNetworkAccessManager: setDeleteOnFinished / setAutoDeleteReplies
- Defaults to false on QNAM, defauts to true here
No CoAP+TCP plans yet

Once we have CoAP server support, we can test client against server
Inadviseable to run a CoAP server on the Qt network test server
- Network too unstable already in TCP, probably a horrible idea to use it with UDP
We should run a local server on the testing VM
- Californium is Java
- We may need to write something with libcoap (C)

We will need it. For example, all OCF devices are both clients and servers.

DTLS support needs to be added to QtNetwork or it will be too difficult
- We just need to design it so that it will work for both the CoAP client and server

We would like to have CBOR support in QtCore.

Would the API be part of QJsonDocument or separate (but looking like it)?
- Thiago's gut feeling is that making it part of QJsonDocument will make it too constrained for future uses (Example: COSE uses integer keys in maps, not strings)
Volunteers to work with Thiago on doing this
- Adrien Leravat (Witekio)
- Frederik
- Shawn
- Alejandro Exojo