10.10.2017, 12:43, "Thiago Macieira" <[email protected]>: > == 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
