> * 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 :) -- /kinkie
