On 8/25/2014 8:21 AM, Daniel Stenberg wrote: > We have to introduce it now so everything before this entry point will > be "older" and we can't make any other differentiations for > already-built applications.
Yep. This has exactly zero utility at _this_ moment in time; it can only be useful later on down the road. Which makes its cost-benefit ratio look really bad. (And, indeed, if you never have a problem like this ever again, it will have been completely wasted effort.) > A working program that just gets recompiled then risks suddenly not work > anymore, in a subtle way even (just like in your case) since the API is > and should documented to work in a specific way... Documenting such > multiple behaviors would not be very nice. > > It makes it somewhat complicated to test and be certain that the checks > and actions really are the correct ones. No arguments here. Autotests would need to be updated to deal with the two "styles" of the API each time you made a functional break. And this new way of doing things would take some getting used to for the developers too -- "my app worked fine with libcurl 7.56, but then I recompiled it and it broke?!" Clear communication would be key here; changes that cause a functional break might deserve their own section in the release notes. I will put in my own plug here though: if the alternative is subtly (or not so subtly) breaking clients in the wild across the board, without any action on their part besides a libcurl upgrade, then I consider this option to be better. > I fear it gives us or fellow contributors less incentives to actually > maintain ABI compatiblity since then you can actually introduce new > behaviors without damaging older applications. This is of course a > double-edged sword as it can then greatly helps us get out from a few > strict rules we are under and better change internals at specific > boundaries. The cultural changes this might create are interesting, to say the least. Some developers would be tempted to create functional breaks all over the place, and it might be hard to convince people that the maintenance burden is bigger than it looks. Everyone would have to be reminded of the documentation and testing cost. This is a power tool to dig you out of deep and painful holes; it probably shouldn't be used to touch up the paint. > In addition, I can't think of any smooth way to add this without > introducing a new function or macro or something that needs to be called > from the application and so. > > Adding a new such function or macro now would force us to add that to > all the examples and then we have created examples that only work from > release N + 1 and not for any older release ever made of libcurl. Well, you can cheat instead. ;) Let's say you wanted to set the functional version per handle instead of globally. I'll use easy_init as the example. curl_easy_init() gets a new interface, curl_easy_init_v(version), that takes an int/string/whatever version parameter. The old curl_easy_init's implementation calls into this new function with "version zero" (the point past which you can't determine which client is which). Define a CURL_FUNCTIONAL_VERSION macro in curl.h that gets updated with every release. (Maybe there's already a version macro that could be used for this purpose.) Then: #define curl_easy_init() curl_easy_init_v(CURL_FUNCTIONAL_VERSION) Clients don't have to know about the new interface -- they'll have the version compiled directly into them. Old clients continue to call into the curl_easy_init entry point, and new/recompiled clients will switch to the macro implementation, which is actually pointing them to the new entry point. At least that's how it works in my head. Poke holes as desired! Jacob Champion LabVIEW R&D National Instruments ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
