On Thu, Jun 26, 2014 at 1:14 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 22 June 2014 14:13, Lieven Govaerts <lgo_at_mobsol.be> wrote:
>> Hi,
>>
>>
>> I propose we start planning a serf 1.4 release.
>>
>> Serf trunk has some features that will be used in the upcoming
>> Subversion 1.9, so I'd like to get 1.4 out when the Subversion devs
>> start releasing 1.9 release candidates. (When is that planned?) Also,
>> I want to start working on HTTP 2.0 support on trunk. This is probably
>> going to take me a couple of months and will require some API changes,
>> I'd like to get the 1.4 release out of the way first.
>>
>> The idea is to create a 1.4.x branch soon, let's say next week Sunday,
>> June 30.
> June 30 is very tight schedule for me: I'm busy with Subversion 1.9.x
> stuff and also
> have several things to resolve in serf 1.4.x (see below). Could you
> move branch time to
> week later at least?
>
>> We can keep backporting changes to that branch for a while,
>> but I'd like to release as soon as the API is stable (see TODO list).
>> AFAIC that can be by the end of next month.
>>
> [..]
>>
>> Fixes:
>> --------
>> r2382: Fix problems with NTLM authentication when accessing local
>> server using alias hostname (Windows)
> While the problem is important, Michael raised some concerns about my fix:
> https://groups.google.com/forum/#!topic/serf-dev/yFPCis1zNNI
>
> These concerns have to be resolved before branch: probably we need add some
> configuration option to change reverse lookup behavior.
>
> [..]
>
>> TODO:
>> =====
>> Blocking the release:
>> ---------------------------
>> * Finalize get_remaining(): Ivan has added this function to the bucket
>> API, but it's only implemented for some buckets.
> As far I remember it's implemented for all buckets where length is known.
>
>> I don't think the new API is in use (don't see it in svn trunk). Does it still serve a
>> purpose?
> This still useful for Subversion. It's currently unused Subversion
> only because serf-trunk has version 2.0.0, not 1.4.0
>
> [...]
>
>> * Logging: there are some TODO's concerning logging. Logging of raw
>> messages is not readable, debugging symbols that need to be removed,
>> negative performance impact of config lookup in socket_writev.
> I'm still want to review logging changes because personally I would
> like to have numbered indexes for configuration options instead of
> strings. To avoid use of apr_hash for better performance.
@Ivan: r2416 eliminates those hash tables that are actually slow, the
ones where the configuration key/value pair are stored in. I've
replaced them by a linked list. Since we only have one or two keys per
category lookup is now a lot faster.
We could have used an array here, but since the config store is part
of the public API and applications are allowed to define their own
keys, we 1) need to partition serf internal and application keys and
2) it's better to not assume that the application dev will use 1, 2,
3... as key numbers. Hence, a linked list is the better option.
I've kept the hash tables that store the per connection/per host
config objects. These are only rarely accessed and are best used with
string keys so there's no problem in using them.
Lieven
>>
>> * set the version to 1.4: I'll do that on the 1.4.x branch.
>>
>> Issues I think we should fix in 1.4:
>> ---------------------------------------------
>> * Fix cancellation of failed requests when an authn callback is set
>> (r2360). See the discussion and proposal to fix this:
>> https://groups.google.com/d/msg/serf-dev/3_HLwF2lVsY/bcR-fatxGB0J
>>
> It still in my todo list :(
>
>> * issue 144: svn commit hangs over https+kerberos. It's not clear to
>> me yet what causes this issue, but getting serf in an endless loop is
>> an issue we should fix. Not blocking 1.4, I doubt a solution will
>> require API changes.
>>
>> 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)
>>
> Unfortunetaly I don't have enough time to work on this now, because
> I've a lot of things to do this summer. So I think we could defer it
> to serf 1.5.0.
>
>> * 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 .
>>
> It looks like nice feature to have. I didn't tested proposed patch yet.
>
>
> --
> Ivan Zhakov
>
> --
> You received this message because you are subscribed to the Google Groups "Serf Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to serf-dev+unsubscribe_at_googlegroups.com.
> To post to this group, send email to serf-dev_at_googlegroups.com.
> Visit this group at http://groups.google.com/group/serf-dev.
> For more options, visit https://groups.google.com/d/optout.
Received on 2014-08-19 10:40:10 CEST