|
| 1 | +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 | +<HTML> |
| 3 | + <HEAD> |
| 4 | + <TITLE> [squid-dev] Proposal: Helper response: concatenated values with custom delimiter |
| 5 | + </TITLE> |
| 6 | + <LINK REL="Index" HREF="index.html" > |
| 7 | + <LINK REL="made" HREF="mailto:squid-dev%40lists.squid-cache.org?Subject=Re%3A%20%5Bsquid-dev%5D%20Proposal%3A%20Helper%20response%3A%20concatenated%20values%20with%0A%20custom%20delimiter&In-Reply-To=%3C69f29587-3d53-40b8-ae4d-a6fb054933e5%40measurement-factory.com%3E"> |
| 8 | + <META NAME="robots" CONTENT="index,nofollow"> |
| 9 | + <style type="text/css"> |
| 10 | + pre { |
| 11 | + white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */ |
| 12 | + } |
| 13 | + </style> |
| 14 | + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> |
| 15 | + <LINK REL="Previous" HREF="010034.html"> |
| 16 | + |
| 17 | + </HEAD> |
| 18 | + <BODY BGCOLOR="#ffffff"> |
| 19 | + <H1>[squid-dev] Proposal: Helper response: concatenated values with custom delimiter</H1> |
| 20 | + <B>Alex Rousskov</B> |
| 21 | + <A HREF="mailto:squid-dev%40lists.squid-cache.org?Subject=Re%3A%20%5Bsquid-dev%5D%20Proposal%3A%20Helper%20response%3A%20concatenated%20values%20with%0A%20custom%20delimiter&In-Reply-To=%3C69f29587-3d53-40b8-ae4d-a6fb054933e5%40measurement-factory.com%3E" |
| 22 | + TITLE="[squid-dev] Proposal: Helper response: concatenated values with custom delimiter">rousskov at measurement-factory.com |
| 23 | + </A><BR> |
| 24 | + <I>Thu Apr 23 13:42:56 UTC 2026</I> |
| 25 | + <P><UL> |
| 26 | + <LI>Previous message (by thread): <A HREF="010034.html">[squid-dev] Proposal: Helper response: concatenated values with custom delimiter |
| 27 | +</A></li> |
| 28 | + |
| 29 | + <LI> <B>Messages sorted by:</B> |
| 30 | + <a href="date.html#10035">[ date ]</a> |
| 31 | + <a href="thread.html#10035">[ thread ]</a> |
| 32 | + <a href="subject.html#10035">[ subject ]</a> |
| 33 | + <a href="author.html#10035">[ author ]</a> |
| 34 | + </LI> |
| 35 | + </UL> |
| 36 | + <HR> |
| 37 | +<!--beginarticle--> |
| 38 | +<PRE>On 2026-04-22 07:24, Andrey K wrote: |
| 39 | +><i> Hello, Amos and Alex, |
| 40 | +</I>><i> |
| 41 | +</I>><i> Thank you for the discussion and the proposed formats. |
| 42 | +</I>><i> |
| 43 | +</I>><i> Since we already support the |
| 44 | +</I>><i>     key=v1 key=v2 |
| 45 | +</I>><i> format, and the |
| 46 | +</I>><i>     key=v1,v2 |
| 47 | +</I>><i> format is currently undocumented, I think we should answer two questions |
| 48 | +</I>><i> first: |
| 49 | +</I>><i> |
| 50 | +</I>><i> 1. Do we really need to support list-values? It seems Alex thinks we |
| 51 | +</I>><i> might not need them at all. |
| 52 | +</I> |
| 53 | +If you have to ask, then the answer is "no" or "not yet": We need a very |
| 54 | +compelling use case to add a "list-values" optimization (when we already |
| 55 | +support lists of values). Since you are not sure, and you were the only |
| 56 | +one making/wanting related changes (AFAICT), we evidently lack such a |
| 57 | +case today. |
| 58 | + |
| 59 | +Rule of thumb: Avoid complex optimizations until their expense can be |
| 60 | +justified by a use case (that can also guide their implementation). |
| 61 | + |
| 62 | + |
| 63 | +><i> 2. If we do, is a comma enough as the default separator? |
| 64 | +</I> |
| 65 | +It is enough as a starting point _if_ we preserve the possibility of |
| 66 | +adding reasonable support for other separators without breaking any |
| 67 | +existing (at that time) helpers. |
| 68 | + |
| 69 | + |
| 70 | +><i> I believe we should settle these points before designing a new format |
| 71 | +</I>><i> for value lists. |
| 72 | +</I> |
| 73 | +I agree. Moreover, if the answer to the first question is "no" (or "not |
| 74 | +yet"), then we do not need to answer the second question (now). |
| 75 | + |
| 76 | + |
| 77 | +Cheers, |
| 78 | + |
| 79 | +Alex. |
| 80 | + |
| 81 | + |
| 82 | +><i> ср, 22 апр. 2026 г. в 00:17, Alex Rousskov: |
| 83 | +</I>><i> |
| 84 | +</I>><i> On 2026-04-21 15:57, Amos Jeffries wrote: |
| 85 | +</I>><i> |
| 86 | +</I>><i> > The helper protocol documents ',' as list delimiter |
| 87 | +</I>><i> |
| 88 | +</I>><i> Where do we document ',' as a delimiter for annotation values in helper |
| 89 | +</I>><i> responses? I cannot find any such text on AddonHelpers page or inside |
| 90 | +</I>><i> cf.data.pre. |
| 91 | +</I>><i> |
| 92 | +</I>><i> > On 22/04/2026 03:11, Alex Rousskov wrote: |
| 93 | +</I>><i> >> [ If there is a real, serious need to optimize that existing |
| 94 | +</I>><i> support, |
| 95 | +</I>><i> >> then ] can we invent another syntax that will not result in |
| 96 | +</I>><i> >> mishandling any existing helper annotation (that is not treated |
| 97 | +</I>><i> as a |
| 98 | +</I>><i> >> list today)? For example, perhaps we can use isKeyNameChar() |
| 99 | +</I>><i> >> restrictions to place the delimiter first, before the annotation |
| 100 | +</I>><i> name? |
| 101 | +</I>><i> >> |
| 102 | +</I>><i> >>      (m=,)name=value1,value2 |
| 103 | +</I>><i> >> |
| 104 | +</I>><i> > |
| 105 | +</I>><i> > Hmm.  When I combine that idea with older proposals floated about |
| 106 | +</I>><i> > kv-pair append/replace syntax there are some nice implications. |
| 107 | +</I>><i> > |
| 108 | +</I>><i> > How about this: |
| 109 | +</I>><i> > |
| 110 | +</I>><i> > 1) change of kv-pair grammar to: |
| 111 | +</I>><i> > |
| 112 | +</I>><i> >     kv-pair = [ '_' ] key [ flag ] '=' ( value / list ) |
| 113 | +</I>><i> |
| 114 | +</I>><i> Yes, AFAICT, placing handling instructions _after_ the key should also |
| 115 | +</I>><i> work (for the same isKeyNameChar) reason) and is more aesthetically |
| 116 | +</I>><i> pleasing than my sketch above. |
| 117 | +</I>><i> |
| 118 | +</I>><i> If we really have to add this new feature, then I would probably use |
| 119 | +</I>><i> curly braces for these optional instructions, to make it similar to our |
| 120 | +</I>><i> logformat %codes: |
| 121 | +</I>><i> |
| 122 | +</I>><i>      name{...}=value... |
| 123 | +</I>><i> |
| 124 | +</I>><i> For example: |
| 125 | +</I>><i> |
| 126 | +</I>><i>      name{m}=value1,value2 |
| 127 | +</I>><i> |
| 128 | +</I>><i> or |
| 129 | +</I>><i> |
| 130 | +</I>><i>      name{m=:}=value1:value2 |
| 131 | +</I>><i> |
| 132 | +</I>><i> |
| 133 | +</I>><i> > * flag does not need to be limited to a single character. It |
| 134 | +</I>><i> could be |
| 135 | +</I>><i> > several. |
| 136 | +</I>><i> |
| 137 | +</I>><i> Any syntax should allow adding safe, backward-compatible support for |
| 138 | +</I>><i> additional/complex instructions in the future, of course, including |
| 139 | +</I>><i> multiple instructions. |
| 140 | +</I>><i> |
| 141 | +</I>><i> |
| 142 | +</I>><i> HTH, |
| 143 | +</I>><i> |
| 144 | +</I>><i> Alex. |
| 145 | +</I>><i> |
| 146 | +</I>><i> _______________________________________________ |
| 147 | +</I>><i> squid-dev mailing list |
| 148 | +</I>><i> <A HREF="https://lists.squid-cache.org/listinfo/squid-dev">squid-dev at lists.squid-cache.org</A> <mailto:<A HREF="https://lists.squid-cache.org/listinfo/squid-dev">squid-dev at lists.squid-cache.org</A>> |
| 149 | +</I>><i> <A HREF="https://lists.squid-cache.org/listinfo/squid-dev">https://lists.squid-cache.org/listinfo/squid-dev</A> |
| 150 | +</I>><i> <<A HREF="https://lists.squid-cache.org/listinfo/squid-dev">https://lists.squid-cache.org/listinfo/squid-dev</A>> |
| 151 | +</I>><i> |
| 152 | +</I> |
| 153 | +</PRE> |
| 154 | + |
| 155 | +<!--endarticle--> |
| 156 | + <HR> |
| 157 | + <P><UL> |
| 158 | + <!--threads--> |
| 159 | + <LI>Previous message (by thread): <A HREF="010034.html">[squid-dev] Proposal: Helper response: concatenated values with custom delimiter |
| 160 | +</A></li> |
| 161 | + |
| 162 | + <LI> <B>Messages sorted by:</B> |
| 163 | + <a href="date.html#10035">[ date ]</a> |
| 164 | + <a href="thread.html#10035">[ thread ]</a> |
| 165 | + <a href="subject.html#10035">[ subject ]</a> |
| 166 | + <a href="author.html#10035">[ author ]</a> |
| 167 | + </LI> |
| 168 | + </UL> |
| 169 | + |
| 170 | +<hr> |
| 171 | +<a href="https://lists.squid-cache.org/listinfo/squid-dev">More information about the squid-dev |
| 172 | +mailing list</a><br> |
| 173 | +</body></html> |
0 commit comments