4 ms·

This begs the question of why all of these protocols should be in one library, instead of one each. If a project is only going to ever use http, why would I ne

This begs the question of why all of these protocols should be in one library, instead of one each. If a project is only going to ever use http, why would I need to bundle in all of the others? Genuinely curious what the advantages are

craftinator 5y ago
My first thought is flexibility and interoperability. If you have one tool, cross platform, that supports a wide variety of protocols, you can use it on both ends of a connection, and easily swap out protocols without having to: 1) install a new tool on both sides 2) learn a new API for each protocol 3) bug check for it It also let's you do all this dynamically, so switching protocols on the fly is trivial.
lanstin 5y ago
It is a good library API with good support for async and that sort of thing. As a user it is less work to integrate the Nth protocol in a library I understand than to read the docs and try to reverse engineer some new API model of how to do things including asynchronous and configurations and TLS/cert management etc. there are a thousand ways to skin the cat, and libcurl is a good one. I want to learn a bunch of new distributed protocols because those are real things; I don’t want to learn a bunch of different APIs to do the same things because those are arbitrary wrappings to the real thing. If an API is successful enough it would be real, but cleverness in API design isn’t that useful without the popularity.
cdelsolar 5y ago
http://begthequestion.info/ http://begthequestion.info/
jolmg 5y ago
What better thing to do with a universal resource locator syntax than to have a universal client? > If a project is only going to ever use http, why would I need to bundle in all of the others? Your project might only ever think to use http, but my project might appreciate having one client for any URL, instead of having to parse URLs myself and decide on separate clients based on a part of it.

craftinator 5y ago

My first thought is flexibility and interoperability. If you have one tool, cross platform, that supports a wide variety of protocols, you can use it on both ends of a connection, and easily swap out protocols without having to: 1) install a new tool on both sides 2) learn a new API for each protocol 3) bug check for it It also let's you do all this dynamically, so switching protocols on the fly is trivial.

lanstin 5y ago

It is a good library API with good support for async and that sort of thing. As a user it is less work to integrate the Nth protocol in a library I understand than to read the docs and try to reverse engineer some new API model of how to do things including asynchronous and configurations and TLS/cert management etc. there are a thousand ways to skin the cat, and libcurl is a good one. I want to learn a bunch of new distributed protocols because those are real things; I don’t want to learn a bunch of different APIs to do the same things because those are arbitrary wrappings to the real thing. If an API is successful enough it would be real, but cleverness in API design isn’t that useful without the popularity.

cdelsolar 5y ago

http://begthequestion.info/ http://begthequestion.info/

jolmg 5y ago

What better thing to do with a universal resource locator syntax than to have a universal client? > If a project is only going to ever use http, why would I need to bundle in all of the others? Your project might only ever think to use http, but my project might appreciate having one client for any URL, instead of having to parse URLs myself and decide on separate clients based on a part of it.