[squid-dev] [PATCH] Log SSL Cryptography Parameters

[Kinkie]

I would prefer more telling (aka long) codes, especially for less common tokens.

On Sun, Dec 13, 2015 at 10:27 PM, Alex Rousskov
<rousskov at measurement-factory.com> wrote:
> On 12/13/2015 01:46 PM, Christos Tsantilas wrote:
>> On 12/13/2015 11:16 AM, Amos Jeffries wrote:
>>> * please make the codes shorter. We still have to work within a
>>> relatively short line length for the entire log format.
>
>
>> Well, I did not fix it in the new patch. We need the other developers
>> opinion.
>>
>> The short names does not improve the speed or something in operation.
>> However they confuses system admins when trying to read a logformat
>> strings.
>> I am suggesting to keep the long names for logformat codes as is.
>
>
> I agree with Christos: Short codes are best for computers and, arguably,
> frequently-used command-line options typed by humans. Long names offer
> better UX in most other cases and should be the default approach for new
> logformat %codes.
>
>
> If Squid cannot support long [wrapped] directives, let's discuss and
> remove that limitation instead of trying harder and harder to cramp a
> growing list of various options into a too-short internal buffer. We
> ought to eventually support something similar to this example:
>
>   logformat myFormat \
>         %ts.%03tu \ # record timestamp [seconds.milliseconds]
>         %6tr \ # response time; TODO: Ask George about units!
>         %>a \ # XXX: our script does not handle IPv6 addresses yet
>         %ssl::>cert_subject \ # TODO: Should we log the issuer?
>         ... many more %codes, including the newer long ones ...
>
> However, improving handling of long [wrapped] lines is a separate issue,
> with its own discussion points (like supporting the combination of a
> comment and line continuation). The proposed feature will work fine
> without those improvements, even if it makes those improvements even
> more desirable.
>
>
> Thank you,
>
> Alex.
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev



-- 
    Francesco