Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One thing I've wished for in curl is for the backends ("handlers") to be more pluggable. This would solve a packaging problem we have in Fedora where we'd prefer to distribute a core curl with backends packaged as subpackages, so that programs that only need (eg) http support would only need to depend on curl-handler-http and curl-core. At the moment the actual solution is to compile separate curl and curl-minimal packages where curl-minimal removes the lesser-used backends, and you have to choose, system-wide, which one to install.

This plus a stable ABI for handlers would also solve the writing backends in other languages problem because another team could contribute a Rust / hyper handler separately.

(I'm sure Daniel has solid reasons for not doing this, not to mention that it's a bunch of work which no one is volunteering to do.)



The curl-minimal solution sounds more transparent and understandable to users, on the other hand.


The problem with curl-minimal is if you install any program that needs full-fat curl, then you're out of luck if you want to keep the minimal install.

With separate curl handlers you'd also be able to find out what protocols your system is configured to access with a command like this [simulated]:

  $ rpm -qa | grep curl-handler- | sort
  curl-handler-ftp
  curl-handler-http
  curl-handler-https
  curl-handler-smb
and similar RPM commands might be used to find out what applications need a particular protocol.


Yep, but still as a user I'd prefer the simpler way, since it will be more clear what's happening ("ok, curl-minimal is being replaced by the full curl when I install this package"). And there will be fewer little splinter packages.

I wonder if there's a place for an additional level of abstraction here, so that the user would just see something like "subcomponent X of the curl package is being installed"...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: