Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: conn.data considered bad
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_cool.haxx.se>
Date: Sun, 10 Jan 2021 18:10:51 +0100
On 1/10/21 5:59 PM, Daniel Stenberg wrote:
> On Sun, 10 Jan 2021, Patrick Monnerat wrote:
>
>> Could be turned at first as:
>>
>> void abcd(struct Curl_easy *data)
>>
>> abcd(conn->data);
>
> Sure it can, and if you can come up with a way where that helps then
> good for you. In my head that's just an intermediate step that I don't
> think is necessary to land separately, but I would proceed and do the
> next step too before submitting the PR...
>
>> For things like handlers and TLS procedures (i.e.: where there are
>> several procedures that must have the same prototype signature), as
>> first (multiple) steps we can rewrite the procedures to turn:
>
> There too, I don't really see the gain in the double-step. Personally,
> I rather instead do it fully at once, but limiting the change to one
> API/concept at a time. But I'm not saying it can't be done that way.
>
The big advantage is you can run the test suite between the small steps !
>>> I don't think we have a lot of wiggle room to do that. Everything we
>>> do in libcurl is oriented around a transfer and properties like
>>> callbacks and VERBOSE are set in the transfer object. We can't
>>> output any logs without also knowing the transfer!
>
>> As the current logging is implemented, I agree. That's why I
>> suggested alternatives.
>
> We're rather tied up in API and ABI behavior so I can't see a lot of
> room to change this... But if you have ideas then I'll certainly listen!
Only one that I don't like at all: having default values to use in
logging procedures when data is NULL :-(
Plase note that nss seems cursed (even in the master branch): test suite
gives valgrind errors and test 300 never finishes.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-10
Date: Sun, 10 Jan 2021 18:10:51 +0100
On 1/10/21 5:59 PM, Daniel Stenberg wrote:
> On Sun, 10 Jan 2021, Patrick Monnerat wrote:
>
>> Could be turned at first as:
>>
>> void abcd(struct Curl_easy *data)
>>
>> abcd(conn->data);
>
> Sure it can, and if you can come up with a way where that helps then
> good for you. In my head that's just an intermediate step that I don't
> think is necessary to land separately, but I would proceed and do the
> next step too before submitting the PR...
>
>> For things like handlers and TLS procedures (i.e.: where there are
>> several procedures that must have the same prototype signature), as
>> first (multiple) steps we can rewrite the procedures to turn:
>
> There too, I don't really see the gain in the double-step. Personally,
> I rather instead do it fully at once, but limiting the change to one
> API/concept at a time. But I'm not saying it can't be done that way.
>
The big advantage is you can run the test suite between the small steps !
>>> I don't think we have a lot of wiggle room to do that. Everything we
>>> do in libcurl is oriented around a transfer and properties like
>>> callbacks and VERBOSE are set in the transfer object. We can't
>>> output any logs without also knowing the transfer!
>
>> As the current logging is implemented, I agree. That's why I
>> suggested alternatives.
>
> We're rather tied up in API and ABI behavior so I can't see a lot of
> room to change this... But if you have ideas then I'll certainly listen!
Only one that I don't like at all: having default values to use in
logging procedures when data is NULL :-(
Plase note that nss seems cursed (even in the master branch): test suite
gives valgrind errors and test 300 never finishes.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-10