> On Aug 12, 2016, at 11:55 AM, Susan Hinrichs > <shinr...@network-geographics.com> wrote: > > Barring the poor formatting of this particular email, this API seems like a > reasonable trade-off.
Yeh I think this is a superset of all the proposals we have seen so far :) What do you think about the implementability/usability of this API? > > > On 8/9/2016 8:29 PM, Alan Carroll wrote: >> What if we made the API a bit more general. >> TSReturnCode TSTxnClientProtocolStackGet(TSHttpTxn txnp, int count, char >> **result, int* actual); >> This function returns an array of static character strings that represent >> the protocol stack for the user agent connection. *result* is an array of >> char const* pointers with at least *count* elements. The protocols are >> listed from higher to lower in *result*. If there is insufficient space in >> *result* the lower protocols are not stored. The number of protocols is >> return in *actual* if *actual* is not NULL. Note that *actual* can be larger >> than *count* - this indicates that protocols were discarded and not put in >> to *result*. Pointers in *result* that are not required are unchanged. No >> element of *result* past the first *count* elements will be modified. >> >> Callers can detect the size of the return array by >> std::min(*actual*,*count*). Alternatively the array can be pre-zero'd and >> the caller can walk until a NULL pointer is found. If this is required then >> *count* can be set to be one less than the actual array size. Callers >> interested in just the top level protocol can pass *count* as 1 with the >> address of a char const* and NULL for *actual*. >> Defined strings: >> Protocol Tag >> HTTP/2 h2HTTP/1.1 http/1.1HTTP/1.0 http/1.0QUIC >> quicTCP tcpUDP udpTLS >> tlsWeb Sockets ws >> >> >> >> >
