> * StringNG: Last time I checked the public branch, there were still many
> previously identified problems that were not fixed. I am guessing that
> Kinkie is sick and tired of these iterations and do not expect him to
> work on that branch beyond its current state until I produce a patch
> with specific fixes (like we did with the MemBlob code).
Sorry for being late in the answer. While it's true that StringNG is
long overdue, and that I am tired of iterating again and again, at the
same itme I want to close it as a project. Unfortunately I cannot
spend daytime work on squid, which means that the time I can devote to
it comes in bursts (loosely tied to me being single or not). It would
probably more time-efficient if you could produce a patch rather than
comments, but whatever help gets us to the bottom of this development
thread is welcome, and I understand that StringNg is not a priority of
yours.
> I do not plan working on StringNG until the above three items are
> closed. Meanwhile, I hope Kinkie will add memory pooling for committed
> MemBlob code. Without it, we probably should not use new strings in core
> code anyway.
It's a performance optimization, I don't see it as a critical factor.
OTOH, StringNg will help us start fixing char* and String (ab)users,
which is a valuable goal per se. However, doing so now would be
premature.
> From user point of view, I do not think StringNG work is a v3.2 blocker.
I agree. I would advise against what has been merged so far however.
We can afford to ship a bit of not-yet-used code.
> From developer point of view, it would be nice to finally get it
> committed and start using it, of course.
I also agree :)
-- /kinkieReceived on Mon Feb 28 2011 - 22:54:32 MST
This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 12:00:14 MST