Re: Proposal: Helper response: concatenated values with custom delimiter

--===============8474320011232759025==
Content-Type: multipart/alternative; boundary="000000000000282d7906500ac677"

--000000000000282d7906500ac677
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello, Amos and Alex,

Thank you for the discussion and the proposed formats.

Since we already support the
    key=3Dv1 key=3Dv2
format, and the
    key=3Dv1,v2
format is currently undocumented, I think we should answer two questions
first:

1. Do we really need to support list-values? It seems Alex thinks we might
not need them at all.
2. If we do, is a comma enough as the default separator?

I believe we should settle these points before designing a new format for
value lists.

What are your thoughts?

Kind regards,
    Ankor.


=D1=81=D1=80, 22 =D0=B0=D0=BF=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 00:17, Ale=
x Rousskov <[email protected]
>:

> On 2026-04-21 15:57, Amos Jeffries wrote:
>
> > The helper protocol documents ',' as list delimiter
>
> Where do we document ',' as a delimiter for annotation values in helper
> responses? I cannot find any such text on AddonHelpers page or inside
> cf.data.pre.
>
> > On 22/04/2026 03:11, Alex Rousskov wrote:
> >> [ If there is a real, serious need to optimize that existing support,
> >> then ] can we invent another syntax that will not result in
> >> mishandling any existing helper annotation (that is not treated as a
> >> list today)? For example, perhaps we can use isKeyNameChar()
> >> restrictions to place the delimiter first, before the annotation name?
> >>
> >>      (m=3D,)name=3Dvalue1,value2
> >>
> >
> > Hmm.  When I combine that idea with older proposals floated about
> > kv-pair append/replace syntax there are some nice implications.
> >
> > How about this:
> >
> > 1) change of kv-pair grammar to:
> >
> >     kv-pair =3D [ '_' ] key [ flag ] '=3D' ( value / list )
>
> Yes, AFAICT, placing handling instructions _after_ the key should also
> work (for the same isKeyNameChar) reason) and is more aesthetically
> pleasing than my sketch above.
>
> If we really have to add this new feature, then I would probably use
> curly braces for these optional instructions, to make it similar to our
> logformat %codes:
>
>      name{...}=3Dvalue...
>
> For example:
>
>      name{m}=3Dvalue1,value2
>
> or
>
>      name{m=3D:}=3Dvalue1:value2
>
>
> > * flag does not need to be limited to a single character. It could be
> > several.
>
> Any syntax should allow adding safe, backward-compatible support for
> additional/complex instructions in the future, of course, including
> multiple instructions.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-dev mailing list
> [email protected]
> https://lists.squid-cache.org/listinfo/squid-dev
>

--000000000000282d7906500ac677
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello, Amos and Alex,<br><br>Thank you for the discussion =
and the proposed formats.<br><br>Since we already support the=C2=A0<div><fo=
nt face=3D"monospace">=C2=A0 =C2=A0 key=3Dv1 key=3Dv2</font>=C2=A0</div><di=
v>format, and the=C2=A0</div><div><font face=3D"monospace">=C2=A0 =C2=A0 ke=
y=3Dv1,v2=C2=A0</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.<b=
r>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 list=
s.<br><br>What are your thoughts?</div><div><br></div><div>Kind regards,</d=
iv><div>=C2=A0 =C2=A0 Ankor.</div><div><br></div></div><br><div class=3D"gm=
ail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">=D1=
=81=D1=80, 22 =D0=B0=D0=BF=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 00:17, Alex R=
ousskov &lt;<a href=3D"mailto:[email protected]">rousskov@me=
asurement-factory.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">On 2026-04-21 15:57, Amos Jeffries wrote:<br>
<br>
&gt; The helper protocol documents &#39;,&#39; as list delimiter<br>
<br>
Where do we document &#39;,&#39; as a delimiter for annotation values in he=
lper <br>
responses? I cannot find any such text on AddonHelpers page or inside <br>
cf.data.pre.<br>
<br>
&gt; On 22/04/2026 03:11, Alex Rousskov wrote:<br>
&gt;&gt; [ If there is a real, serious need to optimize that existing suppo=
rt, <br>
&gt;&gt; then ] can we invent another syntax that will not result in <br>
&gt;&gt; mishandling any existing helper annotation (that is not treated as=
 a <br>
&gt;&gt; list today)? For example, perhaps we can use isKeyNameChar() <br>
&gt;&gt; restrictions to place the delimiter first, before the annotation n=
ame?<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0 (m=3D,)name=3Dvalue1,value2<br>
&gt;&gt;<br>
&gt; <br>
&gt; Hmm.=C2=A0 When I combine that idea with older proposals floated about=
 <br>
&gt; kv-pair append/replace syntax there are some nice implications.<br>
&gt; <br>
&gt; How about this:<br>
&gt; <br>
&gt; 1) change of kv-pair grammar to:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0=C2=A0 kv-pair =3D [ &#39;_&#39; ] key [ flag ] &#39;=3D&#=
39; ( 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>
=C2=A0 =C2=A0 =C2=A0name{...}=3Dvalue...<br>
<br>
For example:<br>
<br>
=C2=A0 =C2=A0 =C2=A0name{m}=3Dvalue1,value2<br>
<br>
or<br>
<br>
=C2=A0 =C2=A0 =C2=A0name{m=3D:}=3Dvalue1:value2<br>
<br>
<br>
&gt; * flag does not need to be limited to a single character. It could be =
<br>
&gt; 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=3D"mailto:[email protected]" target=3D"_blank">squid-=
[email protected]</a><br>
<a href=3D"https://lists.squid-cache.org/listinfo/squid-dev" rel=3D"norefer=
rer" target=3D"_blank">https://lists.squid-cache.org/listinfo/squid-dev</a>=
<br>
</blockquote></div>

--000000000000282d7906500ac677--

--===============8474320011232759025==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
squid-dev mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-dev

--===============8474320011232759025==--