This mostly looks good; thanks. And apologies for delayed response. On Sun, 2017-01-15 at 13:40 -0800, Daniel Lenski wrote: > > +#define OC_PROTO_PROXY?(1<<0) > +#define OC_PROTO_CSD???(1<<1) > +#define OC_PROTO_AUTH_CERT?????(1<<2) > +#define OC_PROTO_AUTH_OTP??????(1<<4) > +#define OC_PROTO_AUTH_STOKEN???(1<<8) That's 0x01, 0x02, 0x04, 0x10, 0x100? and would we add 0x10000 next? Not what you meant to do, I suspect. :) The .description fields for the protocols probably want to be translatable. And let's take a look at how this is handled in NetworkManager-openconnect. See the handling of 'supported_protocols' and the hard-coded strings in the _vt_impl_get_service_add_detail() function... I think we want to be providing both those "pretty name" and "description" strings, don't we? It'd be good to see the NM- openconnect patch as an example of how this new feature would be *used*, as validation that the new API is what's needed. Finally, in Windows we can't allocate and return memory and expect the caller to free it. If we it that way, we need to provide an openconnect_free_supported_protocols() function too. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4938 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170223/4ccf3449/attachment.bin>
