Discussion:
Deprecated Functions?
Weston Schmidt via curl-library
2021-05-04 00:04:36 UTC
Permalink
I'm working on a websocket implementation that leverages libcurl as
it's primary (ideally only) dependency. To that end, I was reading
through some of the "other" curl header files "urlapi.h" "mprintf.h",
and "stdheaders.h" and other documentation I could find on their use.

I found this commit from a few years ago and wondered if the plan was
still to remove mprintf() and friends?
https://github.com/curl/curl/commit/55452ebdff47f98bf3cc383f1dfc3623fcaefefd

Do any such plans also apply for the curl_url_*() or strncasecmp?

Forgive me if it is obvious, I seemed to find little in the email
archive and in the code itself.

Thanks,
Weston Schmidt
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: htt
Daniel Stenberg via curl-library
2021-05-04 06:08:46 UTC
Permalink
Post by Weston Schmidt via curl-library
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.
Post by Weston Schmidt via curl-library
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.
Post by Weston Schmidt via curl-library
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
Eti
Weston Schmidt via curl-library
2021-05-04 19:42:44 UTC
Permalink
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.
Post by Daniel Stenberg via curl-library
Post by Weston Schmidt via curl-library
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.
Post by Weston Schmidt via curl-library
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.
Post by Weston Schmidt via curl-library
Forgive me if it is obvious, I seemed to find little in the email
archive and in the code itself.
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:/
Daniel Stenberg via curl-library
2021-05-05 07:02:04 UTC
Permalink
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/
Aha! Thanks, I'll try to do something about that...
--
/ 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://c
Loading...