Hi Daniel, On 8/19/2014 4:18 PM, Daniel Stenberg wrote: >> From what I can tell from the previous conversations [2] on the topic, >> the official statement seems to be that any SMTP client that wasn't >> setting CURLOPT_UPLOAD was buggy. I'm fine with that, if that's the >> answer (and we'll be adding CURLOPT_UPLOAD to our new client code). >> But as someone looking in from the outside, it seems like it was sort >> of a retroactive decision -- especially since the libcurl SMTP >> examples didn't have it either. > > What's a bug and what's an ABI/API breakage often leads to a judgement > call. We discuss it, we take a decision and we move on. Sometimes not > everyone agree on the way we dealt with a specific issue.
Do you have a gut feel for which way that judgment call typically goes, specifically for CURLOPT compatibility? Or is it truly case-by-case? And are those discussions just something we need to keep an eye out for on the curl-library list, or do they happen somewhere else? >> Put another way: How do I ensure that our current libcurl client code >> (HTTP, SMTP, or otherwise) does not contain other bugs of this nature, >> so that we won't break in the future because of a missing CURLOPT? > > You participate on the mailing list when such issues occur and you speak > up your mind if you disagree with the direction in which we're going. Or > you help us write up more test cases that make sure we maintain certain > behaviors. And you file bug reports when you find bugs and problems. Okay! Well then, here are our/my two cents. (Keeping in mind that we are only one client out of the thousands you have, and we haven't contributed any patches back yet, and that discussions of "bug compatibility" can get contentious...) Typically we'll follow the strategy of "write the smallest amount of code that works", to reduce maintenance and make it harder to write cargo cult code. So, for example, if libcurl example code contains fifteen CURLOPT settings to do task X, but we can do it with ten -- and if the documentation doesn't make those other five seem like they're necessary -- that's what we'd do. I'm certainly rethinking that strategy now, but that's where we were coming up to this point. I'd be surprised if there weren't at least a few other clients out there who think the same way. So for us, retroactively adding CURLOPTs to the "minimum list" required for any given task is an API break. And in our ideal world, that would never happen without an SONAME change. But I'm trying to recalibrate that expectation into something more in line with what the library's actual policy is; hence my earlier questions. (Just to be clear: I'm not trying to say that you should support code that relies on undefined behavior, or code that explicitly disobeys libcurl documentation. I also think that compatibility breaks are perfectly acceptable when it comes to security vulnerabilities, if it means that applications in the wild become safer. I don't think this particular case falls under any of these categories.) All that aside, _if_ one of these breaks is necessary, we'd really like to have a big red flag put into the upgrade notes. Bonus points if clients are given a way to easily revert the behavior (patchset, #define) but I have no idea how common these sorts of breaks are, so I don't know if that's a reasonable request. It'd also be nice to have a baseline guarantee of _some_ level of functional compatibility, in addition to the current API and ABI guarantees. Even something like "libcurl will not break the example code emitted by past versions of the curl executable, except in critical situations such as security vulnerabilities" would go a long way to help us avoid situations like this. > We're (without me being able to speak for anyone else besides myself of > course) determined to keep doing a great product but we of course depend > on people to actually make sure it stays this way. For what it's worth, we think it's a great product, and has been for some time now. Thanks for your work on it, and for your quick response! 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
