Hi, On Thu, Jun 26, 2014 at 11:51 PM, Greg Stein <gst...@gmail.com> wrote: > On Sun, Jun 22, 2014 at 5:13 AM, Lieven Govaerts <l...@mobsol.be> wrote: >>... > >> TODO: >> ===== >> Blocking the release: >> --------------------------- >> * Finalize get_remaining(): Ivan has added this function to the bucket >> API, but it's only implemented for some buckets. I don't think the new >> API is in use (don't see it in svn trunk). Does it still serve a >> purpose? > > > Since we don't know of any users of this API, then I'd suggest it gets moved > to 2.0. > >> >> * comment out 2.0 API: the "Connection and protocol API v2" >> declarations in serf.h aren't implemented yet, we should comment it >> out to avoid adding it to the public API. > > > Right. Though removal on 1.4.x might be a better option. > I've commented these changes out on trunk now, we can undo that after branch creation.
>>... >> >> What about... >> ------------------ >> * SSL session sharing? Ivan's work in r1982 to enable reuse of SSL >> sessions was reverted to make place for a better solution. The >> performance benefits of this work were really good, any interest to >> implement the proposed better solution? >> (see https://groups.google.com/d/msg/serf-dev/W6vNiUlMDDw/t1Pnr0Zq-aQJ) >> >> * OCSP stapling support: Justin posted a patch to add OCSP stapling >> support to serf's OpenSSL layer. We can discuss what benefits it will >> actually bring, but AFAIC besides some more code to support there's no >> harm in adding it, and people will use it if it's available (e.g. the >> place I'm working now requires either CRL or OCSP (stapling) support) >> See https://groups.google.com/d/msg/serf-dev/rbFtTyE9E_w/l5lWaBIBDE0J . > > > If it can reasonably be tested, then sure. Or maybe include it as > experimental in 1.4.x. I'm working on a patch for the MockHTTPinC library to add a OCSP responder and OCSP Stapling support in the mock server, so it can be 'development tested'. Don't think the code is that complex to warrant the "experimental" flag, but I propose we add a On/Off flag anyway. Lieven [..] > > Thanks! > -g > >
