Re: stringng-cherrypick r12764

On 27/09/2013 10:06 p.m., Kinkie wrote:
>>> How about proceeding like this: merge as-is and trust the callers to
>>> know what they're doing, so that I can spend some time on implementing
>>> these flags? It'll be tedious work, but it shouldn't require too much
>>> brainpower. The alternative (blocking StringNG until the conversions
>>> work is done) would stall StringNg even more :(
>>
>> I would go with trusting the callers for now.
> Yay! This means that all is left to do is:
> - addressing your concenr about importing NULLs
> - removing copyright assignments (at least until a guideline is
> defined; if the decision will be to keep them they can always be added
> later)
> - removing the negative-offset test-cases in the unit tests
>
> and then we should be ready for merge, right?
> (we're still missing some bits after this: tokenizer, cachemgr
> integration and some utilities, but these haven't been reviewed yet)

Tokenizer I think should wait on the conclusion of the config file
parser discussions and I will be strting work on HTTP parer updates to
StringNG once it is in trunk. The plans I had for that were to follow
lines very much like Alex is proposing for the latest config parser (but
with HTTPbis WG provided grammar). SNMP, ICP, HTCP, and HTTP/2.0 packet
parsing is from binary+ASCII mixed buffers. All of which places doubt
about the utility of any given SBuf::Tokenizer code until after the
layer aboves' parse needs are clarified.

Amos
Received on Fri Sep 27 2013 - 11:15:06 MDT