[Development] QtCS 2017 CoAP session notes

[Konstantin Tokarev]

10.10.2017, 12:43, "Thiago Macieira" <thiago.macieira at intel.com>:
> == 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
>
> === Testing ===
>
> * 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)
>
> == CoAP server ==
>
> We will need it. For example, ''all'' OCF devices are both clients and
> servers.
>
> == DTLS ==
>
> * 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
>
> == CBOR ==
> We would like to have CBOR support in QtCore.

If you do this, please support stringref extension: http://cbor.schmorp.de/stringref

> * 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
> ** Witekio people
> ** Frederik
> ** Shawn
> ** Alexandro
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin