Re: StringNG merge?

On 06.11.2012 04:24, Alex Rousskov wrote:
> On 11/03/2012 06:56 AM, Amos Jeffries wrote:
>> On 4/11/2012 12:55 a.m., Kinkie wrote:
>>> Hi all,
>>> Is it maybe time to resuscitate StringNG, with the target of
>>> merging
>>> in time for 3.3?
>>
>> It is too late for 3.3 features and polish now.
>> But 3.4 is not scheduled for branching until next March and StringNG
>> should be able to make that IMO.
>
> I hope v3.4 will be branched sooner than March 2013, but I agree that
> StringNG is a good candidate for that version.

Maybe, maybe not. Depends on the rate of feature merges. I pegged the
estimate at 6 months from 3.3 branching, to give us a short beta 3.3 and
some period without any particular beta being supported.

>
>>> If we agree, any preference on how to proceed?
>>
>> Waiting for that agreement. Then merge.
>
> I plan to review the current code this week. IIRC, there were doubts
> whether the new string buffers support header manipulation and I/O
> patterns we need. I need to double check that they do.
>

FYI: the HTTPbis WG is currently investigating whether to go with
deflate, huffman, or diff style compression patterns on HTTP/2.0
headers. So optimizing for the HTTP/1 patterns could become useless in
the next 1-3 years.

I think one of the better optimization patterns we need to aim towards
is pointing the StringNG backend storage at our fixed indexes of header
names, field key names, or even the StatHist listings; whenever a
registered detail is seen and parsed. That way the input buffer does not
end up with needless RefCount locks against it or copies due to logging
or StatHist needs.

Amos
Received on Tue Nov 06 2012 - 00:47:36 MST