[Development] QtCoap: QNAM-like API or not

[Konstantin Tokarev]

14.01.2018, 20:50, "Adrien LERAVAT" <aleravat at witekio.com>:
> Hi all,
>
> Before feature freeze, we wanted to challenge the current API for the CoAP module.
>
> It is currently similar to QNAM APIs:
>
> \code
>
> QCoapClient client;
>
> QCoapReply *reply = client.get(QUrl("1.2.3.4:5683"));
>
> connect(reply, &QCoapReply::finished, this, &MyClass::onFinished);
>
> ...
>
> MyClass::onFinished(QCoapReply* reply)
>
> {
>
>     qWarning() << reply->readAll();
>
>     reply->deleteLater();
>
> }
>
> \endcode
>
> With the clear drawback of explicit memory management needed by users. We made
>
> some tests with a container/RAII object for the reply, and it seems fine, but before
>
> moving forward in this limited timeframe, we wanted to have your feedback.
>
> Sample below:
>
> \code
>
> QCoapClient client;
>
> QCoapRequest request = client.get(QUrl("1.2.3.4:5683"));
>
> connect(request.reply(), &QCoapReply::finished, this, &MyClass::onFinished);
>
> ...
>
> MyClass::onFinished(const QCoapRequest &request)
>
> {
>
>     qWarning() << request.reply()->readAll();
>
> }
> \endcode
>
> In that case, the QCoapReply life is managed with a QSharedPointer<QCoapReply> in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this approach?

I dislike idea of using external reference counting, making it QExplicitlySharedDataPointer would be better

>
> As it wasn't merged to master yet, you can access the repo from its current submission:
>
> https://codereview.qt-project.org/#/c/201311/
>
> Thanks,
>
> Adrien Leravat
>
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin