A broader issue is that Alan had the impression there was a clear
consensus to do this, and so proceeded to do a lot of work. We should
understand how that happened.
Walt
On Fri, Apr 20, 2018 at 7:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Traveling, so keeping this short for now...
>
>> On Apr 20, 2018, at 10:18 AM, Jason Kenny <jke...@oath.com.INVALID> wrote:
>>
>> Is the concern bufferwritter or the use fo bufferwritter in TSDebug. I
>> agree the "extra" value is small for TSDebug. I feel the use of
>> bufferwritter is great within our code base.
>
>
> Many of us have spent significant amounts of time dealing with how to deal
> with he integration of this library on various platforms. I have yet to see
> the benefits here outweigh the work efforts. I have little confidence that
> the code would not continue to be a PITA when dealing with cross platforms /
> compilers. It’s just really pushing the envelope on how compilers implement
> these some of these features.
>
> The other concern I have is that we might be building a library that is to
> difficult to use,that people wont bother and rather just printf things. I
> know you fixed the performance issues that were noticeable before, but this
> is still a complex piece of code that IMO has yet to show value.
>
> Yes, pretty harsh, and we should have had this discussion long ago. I also
> know that some of this work was done to deal with string expansion in
> header_rewrite; but this is definitely not what I had in mind at the time. I
> wanted to just to be able to efficiently expand the %{} conditions in
> strings, not implement printf as it is.
>
> Ciao,
>
> — Leif
>>
>> -Jason
>>
>>> On Thu, Apr 19, 2018 at 5:42 PM, Bryan Call <bc...@apache.org> wrote:
>>>
>>> Replacing Debug()/TSDebug() with BufferWriter/bwformat has little
>>> benefit. Also, I don’t think adding another formatting interface for
>>> strings is something we want to maintain or use.
>>>
>>> The main downside, with snprintf(), I see reading the examples is having
>>> to keep track of the length and position in the buffer if you are calling
>>> snprintf() multiple times. This can be handled writing a simple wrapper
>>> around snprintf(), which I have done before in about 20 lines of code. If
>>> we want to expose a wrapper around snprintf(), I would be in favor of that.
>>>
>>> -Bryan
>>>
>>>> On Apr 19, 2018, at 11:20 AM, Alan Carroll
>>>> <solidwallofc...@oath.com.INVALID>
>>> wrote:
>>>>
>>>> I have several pull requests up currently involving updates to output
>>>> formatting for BufferWriter. I was asked to provide more detail on the
>>>> point of these pulls requests. Anyone who is interested can read this
>>>> document - https://solidwallofcode.github.io/buffer-writer.en.html for
>>> that
>>>> detail.
>>>
>>>
>
