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
