+1. I think getting a consistent API is worth the short term pain. Thursday, February 17, 2011, 6:11:29 PM, you wrote:
> So, I've finished most of this work, and while reading code, and > discussing on IRC, I think we'll need to make one more change. The issue > is that a few APIs uses an "int" return code as a boolean, where 1 means > "success" (e.g. you found a header), and 0 means "failure" (e.g. not > found). I'd like to propose that we change these to use TSReturnCode as > well (TS_SUCCESS and TS_ERROR). > The downside to this is that such APIs now requires code changes in any > existing plugins. It's not impossible to find such cases, but a little > problematic (since TS_SUCCESS == 0, the logic is inversed). I think I > can whip up a Perl script that would produce good warnings on areas in > existing plugin code that the author might need to address the API > changes. A few example APIs that would change include > TSMgmtStringGet() > TSIPLookupMatchFirst() > Are there any objections or other concerns about this change? It should > be notable that there are plenty of other API changes, but in most > cases, the compilers will detect / complain on those. For this, it would > not. > -- Leif
