> > They model their Coap client after QNAM and related classes (like > > QNetworkRequest/Reply pair). > > > > As I understand it now - DTLS or not does not affect this API much - > > they can later > > You don't know that. Until we know how DTLS will work, we won't know if > there's any impact in the front-end API for CoAP. For example, can you use > one CoAP server for both encrypted and not encrypted? Multicast and > unicast? > > What's more, we CANNOT release a full CoAP API until it implements DTLS. > It's just not acceptable to do so otherwise. Therefore, until there's DTLS, > the > API is Technology Preview and subject to change. So I don't feel we need to > review it yet. I have not spent any time myself. > [Maurice Kalinowski]
I guess having it as Technology Preview for a first release is the usual way to go anyways. That way, the API could still be changed afterwards, but also interested parties could get a first impression and suggest adoptions already, even though DTLS is not available yet. Personally, I do not see those two items (missing DTLS, release TP) conflicting. The only "problem" which might exist, if DTLS takes too long to implement and CoAP would stay for a very long time in TP mode. Maurice _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
