I like the idea of providing more information to direct development -
though maybe this could be achieved by enhancing the stand alone
curl-config tool to report back to the 'mothership' instead of
muddying up curl and libcurl codepaths ?

FWIW I think deprecating HTTP/0.9 has a different motivation then user
feature interest eg. security issues, end of life in lots of browsers,
etc.

Jim

On 6 July 2018 at 14:51, Dennis Clarke <dclarke_at_blastwave.org> wrote:
>
> This will be unpopular and may burst into flames upon arrival but here
> goes. From 2 Jul 2018 on this maillist there was an idea proposed by
> Daniel Stenberg to make "HTTP/0.9" an opt in supported feature which I
> assume means we have to select it at compile time. Seems like a great
> idea however I suggested that the entire project just make a policy
> where low usage features be turned into "opt-in" flags and possibly this
> would really reduce the size of the actual day to day run time. However
> how does one determine what is below the low water mark for usage? The
> data from the "annual survey" may not really reflect what is happening
> in the wild. As Daniel says :
>
> - the user survey is unreliable as the ultimate "truth" since it
> is only a small subset of users filling it out
>
> Also :
>
> - I still want to explain my thinking and I hope someone will tell
> me if I forgot something important that makes my plan break or
> just be bad. If nobody says anything, that means nobody objects
> or found a serious problem with the plan (that they can't live
> with).
>
> However the pièce de résistance for me was this :
>
> - sometimes a "single user" of a feature uses libcurl in an
> application used by a billion humans. Such use cases might
> get some extra attention and sympathy.
>
> OKay .. so I went away, made coffee, sat and thought of a really bad
> idea. This one has a real smell to it. Therefore I apologize in
> advance and have my flame suit ready.
>
> Here goes :
>
> What if there existed an "opt-in" feature which would enable
> curl/libcurl to send a usage status message to some end point
> collection server? A trivial message, perhaps just a single
> udp packet with some 128bit binary of flags to indicate that
> some feature is enabled or not. It could be fired out to an
> SSL/TLS port 443 listener once a month perhaps on some random
> day of the month to avoid congestion.
>
> OKay, so there, I said it. A stats collector feature which would allow
> the annual survey data to have a bit more meat to it. Ugly, I know.
>
> Dennis Clarke
> ps: flame suit is ready
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-07-06