> libcurl is now a little over 149,000 lines. The command line tool has 25,800 lines.
Does it have to be? Should it be? Were sub-libraries or some kind of splitting ever considered?
move-on-by•1mo ago
I’m not Daniel, but I think some of these questions are pretty easy to answer.
* Does it have to be?
Of course not. This is a free open source project. Absolutely none of it ‘has to be’. Speaking more towards features, I’m sure a lot could be removed, but why? For example, the newer ‘wcurl’ tool no doubt added to the LoC, and it doesn’t do anything that couldn’t already be done with the CLI- but I certainly appreciate it being created. Thank you Daniel and the cURL team!
* Should it be?
There is a whole list of features being deprecated. Personally, I’ve found cURL’s support timeline and deprecation notices very gracious. Page: https://curl.se/dev/deprecate.html
On the other hand, new things are coming all the time. For example, adding support for HTTP3 and QUIC no doubt added substantially to the LoC, but it would be a glaring omission to not have it.
* Were sub-libraries or some kind of splitting ever considered?
This is the main reason for my response. How would the use of sub-libraries help with anything? At the end of the day, it’s still the same amount of code (maybe even more?), and the same bill-of-materials that must be maintained, no?
MuffinFlavored•1mo ago
> How would the use of sub-libraries help with anything?
* Clearer boundaries - Enforced API contracts between modules prevent the "everything depends on everything" problem that large monolithic codebases develop.
* LLM-friendly architecture - Modular sub-libraries fit within context windows, making it practical to feed specific components to AI tools for documentation, refactoring, or analysis without information loss.
MuffinFlavored•1mo ago
Does it have to be? Should it be? Were sub-libraries or some kind of splitting ever considered?
move-on-by•1mo ago
* Does it have to be?
Of course not. This is a free open source project. Absolutely none of it ‘has to be’. Speaking more towards features, I’m sure a lot could be removed, but why? For example, the newer ‘wcurl’ tool no doubt added to the LoC, and it doesn’t do anything that couldn’t already be done with the CLI- but I certainly appreciate it being created. Thank you Daniel and the cURL team!
* Should it be?
There is a whole list of features being deprecated. Personally, I’ve found cURL’s support timeline and deprecation notices very gracious. Page: https://curl.se/dev/deprecate.html
On the other hand, new things are coming all the time. For example, adding support for HTTP3 and QUIC no doubt added substantially to the LoC, but it would be a glaring omission to not have it.
* Were sub-libraries or some kind of splitting ever considered?
This is the main reason for my response. How would the use of sub-libraries help with anything? At the end of the day, it’s still the same amount of code (maybe even more?), and the same bill-of-materials that must be maintained, no?
MuffinFlavored•1mo ago
* Clearer boundaries - Enforced API contracts between modules prevent the "everything depends on everything" problem that large monolithic codebases develop.
* LLM-friendly architecture - Modular sub-libraries fit within context windows, making it practical to feed specific components to AI tools for documentation, refactoring, or analysis without information loss.