Re: StringNG 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.

StringNG supports (albeit in a not very memory-efficient way right now
in order to maximize correctness checking) global variables. So the
responsibility for doing this falls on the parser IMO. But it can be
done.
I think we're going to be making heavy use of SBuf-indexed maps, so
it'll probably make sense to have a specialized fast-lookup container
for that. One step at a time..

--
    /kinkie