The reason I stayed away from using "item" is that the expert API doesn't really have "types" like the proto* API. It's an "exists" (or doesn't exist) filter. There are dissectors that have added boolean (or type FT_NONE) header fields because the expert info wasn't previously filterable, but they were effectively behaving as "exist or not". I debated creating a field type specifically for expert info, but FT_NONE does the job at the moment.
If you think expert info and the proto API could become "more merged", so that items can double as an int or string type as well as an "expert info type", then I agree your "item" name is appropriate. However, I do like the naming convention of using "format" when printf style arguments are used, which is why I'd like to overtake the existing expert_add_info_format once everything has been converted over.
-----Original Message-----
From: Christopher Maynard <Christopher.Maynard@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, May 25, 2013 10:10 am
Subject: Re: [Wireshark-dev] Expert info is now filterable!
<mmann78@...> writes:
> Quick synopsis:
> expert_add_info - used for static strings
> expert_add_info_format_text - used for formatted (printf) strings
> I'd eventually like to replace the existing expert_add_info_format with the
> expert_add_info_format_text signature when the conversions are complete
> because I think it's the more appropriate name.
I was wondering about the naming convention here. proto_tree_add_text() is
for adding text that isn't filterable, but expert_add_info_format_text(),
even if temporary, would be for adding fields that are filterable. Would it
be better to use the proto* naming convention, something like:
expert_add_info -> expert_add_info_string
expert_add_info_format_text -> expert_add_info_item()
And come to think of it, this is the "expert info" API, so maybe it should be:
expert_info_add_string
expert_info_add_item
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
