<div dir="ltr">Hello, Amos and Alex,<br><br>Thank you for the discussion and the proposed formats.<br><br>Since we already support the <div><font face="monospace">    key=v1 key=v2</font> </div><div>format, and the </div><div><font face="monospace">    key=v1,v2 </font></div><div>format is currently undocumented, I think we should answer two questions first:</div><div><br>1. Do we really need to support list-values? It seems Alex thinks we might not need them at all.<br>2. If we do, is a comma enough as the default separator?<br><br>I believe we should settle these points before designing a new format for value lists.<br><br>What are your thoughts?</div><div><br></div><div>Kind regards,</div><div>    Ankor.</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">ср, 22 апр. 2026 г. в 00:17, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2026-04-21 15:57, Amos Jeffries wrote:<br>
<br>
> The helper protocol documents ',' as list delimiter<br>
<br>
Where do we document ',' as a delimiter for annotation values in helper <br>
responses? I cannot find any such text on AddonHelpers page or inside <br>
cf.data.pre.<br>
<br>
> On 22/04/2026 03:11, Alex Rousskov wrote:<br>
>> [ If there is a real, serious need to optimize that existing support, <br>
>> then ] can we invent another syntax that will not result in <br>
>> mishandling any existing helper annotation (that is not treated as a <br>
>> list today)? For example, perhaps we can use isKeyNameChar() <br>
>> restrictions to place the delimiter first, before the annotation name?<br>
>><br>
>>      (m=,)name=value1,value2<br>
>><br>
> <br>
> Hmm.  When I combine that idea with older proposals floated about <br>
> kv-pair append/replace syntax there are some nice implications.<br>
> <br>
> How about this:<br>
> <br>
> 1) change of kv-pair grammar to:<br>
> <br>
>     kv-pair = [ '_' ] key [ flag ] '=' ( value / list )<br>
<br>
Yes, AFAICT, placing handling instructions _after_ the key should also <br>
work (for the same isKeyNameChar) reason) and is more aesthetically <br>
pleasing than my sketch above.<br>
<br>
If we really have to add this new feature, then I would probably use <br>
curly braces for these optional instructions, to make it similar to our <br>
logformat %codes:<br>
<br>
     name{...}=value...<br>
<br>
For example:<br>
<br>
     name{m}=value1,value2<br>
<br>
or<br>
<br>
     name{m=:}=value1:value2<br>
<br>
<br>
> * flag does not need to be limited to a single character. It could be <br>
> several.<br>
<br>
Any syntax should allow adding safe, backward-compatible support for <br>
additional/complex instructions in the future, of course, including <br>
multiple instructions.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="https://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div>