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: libcurl read-like interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: XSLT2.0 via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 25 Dec 2020 22:41:15 +0100
Sorry Jiahao if I confused you!
To summarise what was said in "previous episodes":
- a "read-like" interface was considered 4 years ago and a quick PoC
(Proof of Concept) was made: fcurl (see https://github.com/curl/fcurl) -
last commit April 2016.
- there was a poll question last year about any interest for a
"read-like" interface.
But since this attempt didn't seem to have sparkled many interest so
far, not speaking for the libcurl team, but I am not under the
impression that this "new API" will be added anytime soon!
I had already pointed to some possible limitations of this PoC, and to
make it brief, I explain on my (too long) last post that doing a
"decent" read-like interface would probably mean a lot of changes in how
things work in the library.
In the mean time, should you need the "read-like" interface (my case for
a fuse driver), it is so trivial to do it from curl_easy_recv(), that
this is a good starting point.
Although this interface does not much, it is a great help to setup up
the connection with added layers like proxies and TLS. It is and already
an existing and supported interface.
Out of curiosity, having read a bit about io_uring (just now), there is
nothing new here! That was the base principle of a defunct O.S. (CTOS) I
used at the beginning of my I.T. career. I just hope io_uring didn't
forget "abort requests". :-)
I can't clearly see how libcurl, and the use case it serves that are
mostly "streams", could really leverage such a framework (apart from the
underlying system calls that could use it).
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-25
Date: Fri, 25 Dec 2020 22:41:15 +0100
Sorry Jiahao if I confused you!
To summarise what was said in "previous episodes":
- a "read-like" interface was considered 4 years ago and a quick PoC
(Proof of Concept) was made: fcurl (see https://github.com/curl/fcurl) -
last commit April 2016.
- there was a poll question last year about any interest for a
"read-like" interface.
But since this attempt didn't seem to have sparkled many interest so
far, not speaking for the libcurl team, but I am not under the
impression that this "new API" will be added anytime soon!
I had already pointed to some possible limitations of this PoC, and to
make it brief, I explain on my (too long) last post that doing a
"decent" read-like interface would probably mean a lot of changes in how
things work in the library.
In the mean time, should you need the "read-like" interface (my case for
a fuse driver), it is so trivial to do it from curl_easy_recv(), that
this is a good starting point.
Although this interface does not much, it is a great help to setup up
the connection with added layers like proxies and TLS. It is and already
an existing and supported interface.
Out of curiosity, having read a bit about io_uring (just now), there is
nothing new here! That was the base principle of a defunct O.S. (CTOS) I
used at the beginning of my I.T. career. I just hope io_uring didn't
forget "abort requests". :-)
I can't clearly see how libcurl, and the use case it serves that are
mostly "streams", could really leverage such a framework (apart from the
underlying system calls that could use it).
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-25