Feature 2914924 entails adding QoS support for curl and libcurl. This exposes the following deficiency in curl:
Hard-coding QoS settings into libcurl is Draconian, and mostly broken, since (a) many sites will want to hand-tune their QoS settings on a per-protocol basis, and (b) still other sites won't want to deploy QoS at all because of legacy routers that don't understand RFC-2474 and later.
Further, using per-user options to deploy QoS represents a major trust obstacle, since users generally act in their own interests and not in a cooperative, collaborative, or altruistic way. It's also difficult to add new defaults to the existing profiles of dozens or even hundreds of users... but it's much easier to edit a single system-wide defaults file.
One might even argue that some defaults should *only* be exposed at a system-wide level, and not be settable at a per-user level (such as the forced use of an HTTP or Socks proxy... or in this case, QoS tagging).
The lack of such granularity (and partitioning) of control could be a blocker for feature 2914924.
I suggest you take this topic to the curl-library list for discussion. Not many people will bother to read or comment to feature requests posted here...
Well, I brought it up on the ML, but there's not a whole lot of discussion going on...
Yeah, did that... not a whole lot of people responding... so what next?
QoS support