Re: [PATCH] meta_header option

On 10/11/2012 07:32 PM, Amos Jeffries wrote:
> On 12/10/2012 4:05 a.m., Alex Rousskov wrote:
>> On 10/11/2012 05:21 AM, Amos Jeffries wrote:

>>> If you can avoid calling the
>>> list of key:pair entries *headers* it would be less confusing.

>> Here are a few other naming options to consider, from the ones I like
>> the most to the ones I like the least:
>>
>> 1a) annotation key value ...
>> logformat ... %{key}annotation ...
>>
>> 1b) note key value ...
>> logformat ... %{key}note ...
>>
>> 2a) marker key value ...
>> logformat ... %{key}marker ...
>>
>> 2b) mark key value ...
>> logformat ... %{key}mark ...
>>
>> 3) stamp key value ...
>> logformat ... %{key}stamp ...
>>
>> 4) label key value ...
>> logformat ... %{key}label
>>
>> 5) info key value ...
>> logformat ... %{key}info
>>
>>
>> All of which can be prefixed with "meta_", "xaction_", or "master_"
>> prefixes (with varying degree of appropriateness).

> Of the above I like "label" or "note".

If there are no other opinions, I suggest "note" (short for annotation).

> I got a request to implement stacked tags in external ACL the other day.
> It would seem they are suited well for combining with this feature. How
> about "tag" or "meta_tag" ?

I assume stacked tags are key:value pairs. Today, tags are essentially
anonymous or valueless annotations (values without keys or keys without
values). Please correct me if I am wrong.

The reason I did not include "tag" in the above names is because I was
worried that preserving compatibility with the existing tags will create
a mess. Here are a few potentially messy areas:

* The existing tag ACL syntax is not easily extensible to something that
works with key:value pairs. If we make the first argument after the
"tag" type a key name, old configs with multiple tags will continue to
work (but will work incorrectly). Most likely, we will need a new ACL
type name anyway.

* I am not sure how to deal with "class 5" delay pools grouping if tags
have keys and values. Group by keys only? Group by both keys and values?
May have to be configurable.

* Old tag ACLs in existing configs may suddenly and unexpectedly start
matching new annotations, especially if those new annotations have empty
values.

* Some admins do not want annotations to appear in ICAP and eCAP
requests without their explicit control. The proposed implementation
takes care of that because annotations are only added after adaptation
is completed (and there is adaptation_meta for the opposite cases). If
old tags become annotations, we would need to preserve that status quo
for now. (Eventually, I am sure that somebody will need to send some
tags/annotations to adaptation services, creating more problems.)

Overall, I agree that it would be nice to have one name/concept for all
annotations, but reusing "tag"s may create a mess that will either
significantly delay the new feature acceptance (folks will keep asking
for new ways to resolve conflicts with the old tags) or will cause
upgrade problems. It may be better to leave "tag"s to old configs and
standardize on new "note"s going forward (e.g., add them to external
ACLs). What do you think?

Thank you,

Alex.
Received on Fri Oct 12 2012 - 04:10:31 MDT