>
> Are you planning on putting stuff into the protocol dissectors
> *themselves* that handle this,
That's certainly a possibility, which allows a lot of flexibility, but which
is probably quite a bit of work. Maybe some architecture is possible where
the dissectors themselves register some kind of export fields? People could
then add these things then gradually.
>or are you just thinking of, say,
> exporting the values of particular protocol-tree fields, so that the
> dissectors don't have to know about this?
I don't really see how you could do this without building the knowledge
into the dissector? The dissector would have to add some meta information
(e.g field name) about the fields it puts in the tree at startup I guess.
Maybe we could add a parameter to the proto_tree_add routines that would
contain the export information like field name, protocol to which it belongs
etc. The problem is that this would cause overhead in every packet that is
processed. The export format string is also different from the format string
you'd use in the display tree, you typically just want the values of the
fields without blabla in front of them.
The other alternative may be to put all export stuff within an if/then that
is not processed when exporting is disabled, which might be more efficient
but duplicates some of the effort of writing dissectors.
>
> Are you thinking of, for example, one comma-separated-list
> per protocol,
I think one line per packet would be preferrable, the fields themselves
could come from different protocols e.g the IP addresses from the IP header,
a TCP sequence number,... depending on the selection the user makes in tree.
Only the packets that are selected by the filters in the bottom of the main
window should be exported.
> with the list being on a single line?
>
