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
Received on 2014-08-26