On Sun, 2013-03-10 at 11:18 -0400, John Morrissey wrote: > On Sat, Mar 09, 2013 at 10:40:30PM +0000, David Woodhouse wrote: > > On Fri, 2013-03-08 at 21:48 -0500, John Morrissey wrote: > > > On Thu, Mar 07, 2013 at 11:55:18PM +0000, David Woodhouse wrote: > > > > On Thu, 2013-03-07 at 18:39 -0500, John Morrissey wrote: > > > > > - openconnect_set_stoken_mode no longer accepts the use_stoken > > > > > argument and instead always tries to initialize libstoken when > > > > > called. This makes sense in openconnect(8), but I'm not sure how > > > > > much of a concern this API change is for upstream consumers of > > > > > libopenconnect. I also wasn't sure how to account for this in > > > > > libopenconnect.map.in. > > > > > > > > You can't account for it. It's an ABI break and it would take us to > > > > libopenconnect.so.3. I'd like to avoid this change, if possible. > > > > > > Sure, it's easy enough. See this iteration of the patch. > > > > Hm, but now your openconnect_set_oath_mode() API is inconsistent with > > openconnect_set_stoken_mode(). > > > > I'd probably be inclined to make them match. > > > > Or even to use openconnect_set_stoken_mode() for *both*. Just pass zero > > to disable, 1 for stoken and 2 for OATH. > > Actually, I'm wondering whether revving the API is unavoidable at this > point. 4.99 was released last month, which revved the API to include > libstoken support, and if we add TOTP support to API v2.1, it makes it > harder for consumers to determine whether the OATH-related functions are > available (they'd have to do their own autoconf checks instead of simply > checking the API version). It seems that adding symbols to the API has > resulted in a version bump in the past, too. There's a different in bumping from 2.1 to 2.2, and bumping from 2.1 to 3.0. Yes, whenever we add any new functions we should bump the minor revision. But it remains *compatible*. Anything which was linked against 2.0 or 2.1 will still work fine. If we *change* a function or remove it, however, that's an incompatible change and that means we need to go to 3.0. And rebuild everything that was linked against libopenconnect. > How about revving the API, making the TOKEN_MODE_* enum a typedef in > openconnect.h, and adding openconnect_set_token_mode() that takes an > OC_TOKEN_MODE_*? > > That way, the symbol naming is clear in what it's doing (i.e., that it's not > RSA/libstoken-specific), there are no magic numbers to pass thanks to the > enum typedef, and there's a single symbol to call. We can leave > openconnect_set_stoken_mode() as a shim in front of > openconnect_set_token_mode() for transparent backwards compatibility. Sounds reasonable. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6171 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130310/6d1ebdcd/attachment-0001.bin>
