4 ms·

I guess I'm not sure what's left to do for a couple of hours every day on curl after 23 years (given that it fits into the unix philosophy of do one thing, but

I guess I'm not sure what's left to do for a couple of hours every day on curl after 23 years (given that it fits into the unix philosophy of do one thing, but do it well)? Are there that many new features? Lots of bugs to fix? (I wouldn't guess so) Seems like it would only need a couple of hours of maintenance/month by now given the functionality.

zerocrates 6y ago
I don't know the details of curl's development, but at least some of it must be just keeping pace with the shifting infrastructure of the internet: HTTP/2/3/QUIC/whatever, changes in TLS and the underlying libraries, that kind of thing.
touisteur 6y ago
There's always a new version of HTTP around the corner...
selcuka 6y ago
He answered that in the same tweet thread: > we add features, improvements and bug-fixes continuously. With 240 command line options , 26 transfer protocols and countless combinations of things done over a crazy Internet that's just the nature of it all...
willcipriano 6y ago
Curl supports: "DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, HTTP/2, HTTP/3, cookies, user+password authentication (Basic, Plain, Digest, CRAM-MD5, SCRAM-SHA, NTLM, Negotiate and Kerberos), file transfer resume, proxy tunneling and more." I could see creating quality implementations of each of those taking that long. https://curl.se/ https://curl.se/
- UncleOxidant 6y ago
  MQTT even?
  - ObsoleteNerd 6y ago
    Yup: https://curl.se/docs/mqtt.html https://curl.se/docs/mqtt.html
- gfxgirl 6y ago
  That sounds like a bad architecture and a bloated app. It's like if VSCode decided "we don't do plugins, everyone commit your idea directly into our main repo" A sensible plugin architecture would let you do either curl --plugin=LDAP or a naming convention would load the appropriate plugin based on the protocol. Yes I know, armchair code design. And I also know it's nice not to have to deal with configuration, a large app "just works" (though FYI, it does have 15-20 dependencies which are similar to plugins, it has 3 direct and more indirect dependencies). But, 2hrs a day * 23years = 16790hrs!!!!! Something seems wrong for that much time to be spent on "curl" Just to be clear, first, thanks so much for curl! And second, of course having not touched the code ever I have no idea why it required 16k hours of dev time and continues to require more, it could totally be justified. I'm only saying that at a glance, 2hrs a day, 23years sounds surprising and it makes me wonder if there isn't some ways to reduce the load.
  - chris_wot 6y ago
    I doubt re-architecting into modules would make the bugs in each of those protocols go away. The bugs would still be in the modules. You seem to be conflating curl as only an app that deals with http/https. Curl really does a lot more.
    - tephra 6y ago
      Mainly it is also a library that others can use for all of those protocols and SSL backends.
    - 6y ago
jtsiskin 6y ago
https://curl.se/docs/manpage.html https://curl.se/docs/manpage.html
mr_mitm 6y ago
Just check the issue tracker for what kind of things he is working on: https://github.com/curl/curl/issues https://github.com/curl/curl/issues Curl has 170k lines of code, so it's bound to require some maintenance.

zerocrates 6y ago

I don't know the details of curl's development, but at least some of it must be just keeping pace with the shifting infrastructure of the internet: HTTP/2/3/QUIC/whatever, changes in TLS and the underlying libraries, that kind of thing.

touisteur 6y ago

There's always a new version of HTTP around the corner...

selcuka 6y ago

He answered that in the same tweet thread: > we add features, improvements and bug-fixes continuously. With 240 command line options , 26 transfer protocols and countless combinations of things done over a crazy Internet that's just the nature of it all...

willcipriano 6y ago

Curl supports: "DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, HTTP/2, HTTP/3, cookies, user+password authentication (Basic, Plain, Digest, CRAM-MD5, SCRAM-SHA, NTLM, Negotiate and Kerberos), file transfer resume, proxy tunneling and more." I could see creating quality implementations of each of those taking that long. https://curl.se/ https://curl.se/

UncleOxidant 6y ago
MQTT even?
- ObsoleteNerd 6y ago
  Yup: https://curl.se/docs/mqtt.html https://curl.se/docs/mqtt.html
gfxgirl 6y ago
That sounds like a bad architecture and a bloated app. It's like if VSCode decided "we don't do plugins, everyone commit your idea directly into our main repo" A sensible plugin architecture would let you do either curl --plugin=LDAP or a naming convention would load the appropriate plugin based on the protocol. Yes I know, armchair code design. And I also know it's nice not to have to deal with configuration, a large app "just works" (though FYI, it does have 15-20 dependencies which are similar to plugins, it has 3 direct and more indirect dependencies). But, 2hrs a day * 23years = 16790hrs!!!!! Something seems wrong for that much time to be spent on "curl" Just to be clear, first, thanks so much for curl! And second, of course having not touched the code ever I have no idea why it required 16k hours of dev time and continues to require more, it could totally be justified. I'm only saying that at a glance, 2hrs a day, 23years sounds surprising and it makes me wonder if there isn't some ways to reduce the load.
- chris_wot 6y ago
  I doubt re-architecting into modules would make the bugs in each of those protocols go away. The bugs would still be in the modules. You seem to be conflating curl as only an app that deals with http/https. Curl really does a lot more.
  - tephra 6y ago
    Mainly it is also a library that others can use for all of those protocols and SSL backends.
  - 6y ago

jtsiskin 6y ago

https://curl.se/docs/manpage.html https://curl.se/docs/manpage.html

mr_mitm 6y ago

Just check the issue tracker for what kind of things he is working on: https://github.com/curl/curl/issues https://github.com/curl/curl/issues Curl has 170k lines of code, so it's bound to require some maintenance.