I was thinking about how I would implement certain tap features, and I
realized that I'd most likely want to define recursive taps... Tap listeners
that can call their own tap listeners.
One example of how to use this would be generation of the traffic summary...
Say for instance the top level summary tap is called.
It looks at the first item in proto_tree and finds the entry who's filter
field/protocol is "frame"...
so it looks to see if it has a sub-tap for "frame" and creates it if it
doesn't already have one...
Then it calls that tap and passes in a pointer to the "frame" entry in
proto_tree.
The next tap looks for the next top level entry and finds "ip"
(optionally creates "ip" sub-tap)
then calls the "ip" tap with a pointer to the "ip" entry in proto_tree
This next tap sees "udp"
The next one sees "rtp"
...
Then a "draw" call is passed a pointer to the top level summary tree node.
Each tap print's its information into that tree node
If there are sub-taps, it turns the node into a tree itself
For each sub-tap, it calls the sub-tap draw function and passes in a tree node
that is a child of the original tree node passed in.
I guess that I'm interested in how well this fits into the current tap
scheme... There would still be only one registration at the beginning, but
then multiple init_tap_listener calls. I have not looked into the capability
of a tap listener to remember/manipulate sub-tap-listeners... but I thought
I'd get the idea out and see what kind of commentary it generated. At the
very least there will be some implementation nuances that a recursion-aware
implementation will take into account... one would be to keep a record of
private tap listeners separate from ones that are called through the normal
tap mechanism.
