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: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Sun, 10 Jan 2021 17:59:22 +0100 (CET)
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.
>> 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!
Date: Sun, 10 Jan 2021 17:59:22 +0100 (CET)
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.
>> 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!
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-01-10