On 18 January 2018 at 10:07, Konstantin Tokarev wrote:
>
>
> Heap corruption can be detected with lots of existing tools, e.g. ASAN. It
> also won't be left unnoticed until it's too late, unlike memory leaks which
> may suddenly pop up when amount of data increases.
>
> Debugging out of memory co
18.01.2018, 12:58, "Adrien LERAVAT" :
>> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
>> Sent: Thursday, January 18, 2018 10:42 AM
>>
>>> The API sounds interesting, but it's a departure of what we are used in
>>> QNAM.
>>> What happened to the idea of using a setter on the manager,
> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> Sent: Thursday, January 18, 2018 10:42 AM
>
>> The API sounds interesting, but it's a departure of what we are used in
>> QNAM.
>> What happened to the idea of using a setter on the manager, for making the
>> replies self-delete if want
14.01.2018, 20:50, "Adrien LERAVAT" :
> 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, &QCoap
18.01.2018, 12:35, "Adrien LERAVAT" :
> On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
>> > In that case, the QCoapReply life is managed with a
>> > QSharedPointer in the request.
>> >
>> > QCoapRequest does not inherit from QObject. Anyone sees a problem with
>> > this approach?
>
On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> > In that case, the QCoapReply life is managed with a
> > QSharedPointer in the request.
> >
> > QCoapRequest does not inherit from QObject. Anyone sees a problem with
> > this approach?
> The API sounds interesting, but it's a departur
On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote:
> 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.
I don't see a way
On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?
The API sounds interesting, but it's a departure of what we a
ards,
Timur.
From: Development
on behalf of Maurice Kalinowski
Sent: Tuesday, January 16, 2018 8:40:03 AM
To: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] QtCoap: QNAM-like API or not
> > They model their Coap client after QNAM and related classes (li
> > 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
On Sunday, 14 January 2018 22:15:15 PST Timur Pocheptsov wrote:
> > I don't think we can make any decisions on CoAP until DTLS support is
> > there. It may influence what the CoAP API looks like.
>
> Thiago, could you, please, clarify this?
Sure. There's no DTLS API. Therefore, CoAP API cannot be
;s none of them
exactly).
Best regards,
Timur.
From: Development
on behalf of Thiago Macieira
Sent: Monday, January 15, 2018 5:55:41 AM
To: development@qt-project.org
Subject: Re: [Development] QtCoap: QNAM-like API or not
On Sunday, 14 January 2018 09:
On Sunday, 14 January 2018 09:49:48 PST Adrien LERAVAT wrote:
> Hi all,
>
>
> Before feature freeze, we wanted to challenge the current API for the CoAP
> module.
I don't think we can make any decisions on CoAP until DTLS support is there.
It may influence what the CoAP API looks like.
--
Thi
On 14 January 2018 at 19:49, Adrien LERAVAT wrote:
> 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 feed
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:
15 matches
Mail list logo
