|From: Ulf Lamping
|
|
|Olivier Biot wrote:
|
|>From: Ulf Lamping
|>
|>
|>| Hi List!
|>|
|>| It's sometimes confusing to distinguish between protocol fields
|>derived
|>| from the capture data and fields that are generated by Ethereal
|>while
|>| dissecting "from knowledge" (e.g. from context information).
Snip
|>It is a good idea to provide such a distinction between information
|>within the protocol packet and generated information.
|>
|>Some other options:
|> a. Prepend or append an asterisk to the field name
|> b. Render the field differently (e.g., italics in Ethereal)
|>
|>Once we have agreed on some output format we may first want to edit
|>the reassembly code as that will impact *all* dissectors that use
|>reassembly at once.
|
|Hmmm, I only thought of simply renaming the output format
|string in the
|hf_register_info fields, e.g. "Response in frame" -> "[Response in
|frame]".
|
|It might be even a better idea to provide this info into the
|hf_register_info by adding it in a "machine friendly" format, like
|or'ing a flag into the FT_xy fields.
I agree with you. This way an end-user may decide what to do with a given
type of header fields (inclusive showing/hiding them and choosing how to
render them).
Maybe we need to specify this distinction in the PDML language too.
Also note that fields may have the hidden flag and the generated flag on at
the same time.
|As this will be definitely the better technical solution, it would
|require changes at least in the packet tree rendering and I don't have
|much knowledge if this can easily be done.
|
|So the hf_register_info entry could look, like: FT_FRAMENUM |
|FT_GENERATED, or we could provide another set of field registration
|functions, like: proto_tree_add_uint_generated()
Here we need to be careful as today the FT_* are an enum which may be just
one single 8-bit byte.
We however still have some spare room in the HFILL macro to accommodate a
bitfield without requiring us to edit all dissectors. We could even write
HFILL for default, HFILL_HIDDEN for hidden, HFILL_GENERATED for generated
and HFILL_GENERATED_HIDDEN for hidden generated fields, but there are
certainly other worthwile approaches.
|This would make it possible to do various formatting of the
|output later.
Yes, for example by means of preferences!
|Anyone an idea of how much effort that would be?
Add the basic framework to the field registration: minimal.
Add the field rendering changes: minimal, mainly GTK+.
Review the dissectors: potentially huge, but not required for technically
running Ethereal.
Regards,
Olivier