On 06/15/2014 12:07 AM, Amos Jeffries wrote:
> On 15/06/2014 4:58 a.m., Alex Rousskov wrote:
>> On 06/11/2014 08:52 AM, Tsantilas Christos wrote:
>>
>>> I must also note that this patch adds an inconsistency. All annotation
>>> key=values pairs received from helpers, accumulated to the existing key
>>> notes values. The clt_conn_id=Id pair is always unique and replaces the
>>> existing clt_conn_id=Id annotation pair.
>>> We may want to make all annotations unique, or maybe implement a
>>> configuration mechanism to define which annotations are overwriting
>>> their previous values and which appending the new values.
>>
>> I suggest making all annotations unique (i.e., new values overwrite old
>> ones) because helpers that want to accumulate annotation values can do
>> that by returning old values along with new ones:
>>
>> received by helper: name=v1
>> returned by helper: name=v1,v2
>>
>> Please note that the opposite does not work: If annotation values are
>> always accumulated, a helper cannot overwrite/remove the old value.
> Doing that would mean passing all existing annotations to every helper
> lookup.
Why would that mean the above?
AFAICT, the helper should get only the annotations it needs. That need
is helper-specific and, hence, is configurable via the various _extras
and equivalent directives. That is already supported and does not need
to change.
Here is the overall sketch for supporting "unique annotations":
1. Send the helper the annotations it is configured to get
(no changes here).
2. For each unique annotation key received from the helper,
remove any old annotation(s) with the same key.
3. Store annotations received from the helper
(no changes here).
To support explicit annotation deletion, we can adjust #3 to skip
key-value pairs with the value equal to '-'.
HTH,
Alex.
Received on Mon Jun 16 2014 - 15:36:40 MDT
This archive was generated by hypermail 2.2.0 : Fri Jun 20 2014 - 12:00:12 MDT