On Apr 9, 2014, at 7:16 PM, Guy Harris <g...@alum.mit.edu> wrote: > We might want to add syntax so that, for a field with a scale factor of 0.5, > we might have > > wlan.rate = raw(22) > > or > > wlan.rate = 11 > > (no, that was not a randomly-chosen field example :-)). Other suggestions > for the syntax are welcome.
This may seem crazy, but you asked so... I've often thought it would be nice if the fields which have multiple representations and properties could be automatically handled such that display filter sub-names were automagically available/understood, such as the following for the single "wlan.rate" field: wlan.rate == 11 wlan.rate.value == 11 wlan.rate.raw == 22 wlan.rate.scale == 0.5 wlan.rate.units == "bps" wlan.rate.exists == TRUE ... In other words, either have the display filter mechanism automatically understand those last tokens... or have the header_field_info registration mechanism auto-create them, and have the proto_add_item routines automatically add them in the tree as well. (as a sub-tree, so you could expand the field to see the detailed info, and no explicit dissector C-code needs to be written to add those fields or subtree items) The point is they just feel like inherent properties/attributes of the field, as if the field were an object with members. (a la C++, Java, etc.) And furthermore we should be able to create a new ftype of FT_URI, such that for a field named "http.request.uri", it should automagically enable me to do stuff like this: http.request.uri == "http://wiki.wireshark.org/DisplayFilters"; http.request.uri.scheme != "https" http.request.uri.port == 80 http.request.uri.path == "DisplayFilters" http.request.uri.host == "wiki.wireshark.org" ... and even this crazy idea: *.uri.host == "wiki.wireshark.org" // matches in any URI's host *.uri.host contains "wireshark" // matches in any URI's host Obviously it doesn't make sense to do this for every complex field, but URIs happen to be common in multiple protocols; though sadly their structure might not be similar enough across protocols to warrant generalizing. -hadriel ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
