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: Deprecated Functions?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Weston Schmidt via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 4 May 2021 12:42:44 -0700
Thank you for your response. The position makes a lot of sense. The
URL API does look very helpful :). I see your point on them being a
'mistake' in the API, but they are a very useful one.
As to why I mistakenly grouped the URL APIs ... I didn't see them on
the main doc pages. I could find them with google, but they weren't
listed out with the others here: https://curl.se/libcurl/c/
Also now there are a few emails in the archive that will help the next person.
On Mon, May 3, 2021 at 11:08 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 3 May 2021, Weston Schmidt via curl-library wrote:
>
> > I found this commit from a few years ago and wondered if the plan was
> > still to remove mprintf() and friends?
>
> Only if we ever decide to break the API, which we will work hard not to...
>
> I think adding them to the API was a mistake to begin with but they're there
> now and we're going to support them for as long as we maintain the current
> API. (And to make it clear: that mistake was mine)
>
> That's also a reason why they're so badly documented. Lame escuse, I know. One
> of these days I'll make sure we get *proper* man pages done for them.
>
> > Do any such plans also apply for the curl_url_*() or strncasecmp?
>
> I presume you mean curl_strequal? That has a similar story, yes. I think it
> was wrong to add it, but it's there and we will support it.
>
> I don't know why you'd suspect the URL API to be in the same situation as
> that's a fairly new member of the libcurl API family. This is rather an API
> that it took a long time for us to introduce and that I think totally belongs
> in libcurl and helps applications.
>
> Not that the difference matters much to users. They're in the API/ABI and
> we'll support them for as long as possible.
>
> > Forgive me if it is obvious, I seemed to find little in the email
> > archive and in the code itself.
>
> It might be a bit hard to find, but the key to it all is found on:
> https://curl.se/libcurl/abi.html and this quote:
>
> We are determined to bump the SONAME as rarely as possible. Ideally, we
> never do it again.
>
> --
>
> / 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.html
Received on 2021-05-04
Date: Tue, 4 May 2021 12:42:44 -0700
Thank you for your response. The position makes a lot of sense. The
URL API does look very helpful :). I see your point on them being a
'mistake' in the API, but they are a very useful one.
As to why I mistakenly grouped the URL APIs ... I didn't see them on
the main doc pages. I could find them with google, but they weren't
listed out with the others here: https://curl.se/libcurl/c/
Also now there are a few emails in the archive that will help the next person.
On Mon, May 3, 2021 at 11:08 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 3 May 2021, Weston Schmidt via curl-library wrote:
>
> > I found this commit from a few years ago and wondered if the plan was
> > still to remove mprintf() and friends?
>
> Only if we ever decide to break the API, which we will work hard not to...
>
> I think adding them to the API was a mistake to begin with but they're there
> now and we're going to support them for as long as we maintain the current
> API. (And to make it clear: that mistake was mine)
>
> That's also a reason why they're so badly documented. Lame escuse, I know. One
> of these days I'll make sure we get *proper* man pages done for them.
>
> > Do any such plans also apply for the curl_url_*() or strncasecmp?
>
> I presume you mean curl_strequal? That has a similar story, yes. I think it
> was wrong to add it, but it's there and we will support it.
>
> I don't know why you'd suspect the URL API to be in the same situation as
> that's a fairly new member of the libcurl API family. This is rather an API
> that it took a long time for us to introduce and that I think totally belongs
> in libcurl and helps applications.
>
> Not that the difference matters much to users. They're in the API/ABI and
> we'll support them for as long as possible.
>
> > Forgive me if it is obvious, I seemed to find little in the email
> > archive and in the code itself.
>
> It might be a bit hard to find, but the key to it all is found on:
> https://curl.se/libcurl/abi.html and this quote:
>
> We are determined to bump the SONAME as rarely as possible. Ideally, we
> never do it again.
>
> --
>
> / 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.html
Received on 2021-05-04