Pia Sahlberg wrote:
> This example does not need recursive taps. It is sufficient to just tap on
> "frame" and build/maintain a linked tree in the tap extension.
> To find out the relation of protocols, ie which protocols are carried
> ontop of which other, just inspect the edt variable and update the state
> variables to the tap extension accordingly.
> There is no need to tap from anything else than "frame" for this type of
> extension.
For recursive taps, I don't necessarily mean calling the same tap over and
over, but potentially a different tap. The data collection and draw routines
could be combined in potentially novel ways...
I recognize that a tap-listener can maintain its own tree, and all the
maintenance associated with it. I think that a recursive implementation is more
simplistic and less error prone. It would be nice to allow a simplistic
recursive tap, with the option of a looping, non-recursive, tree-managing,
memory-managing version when somebody gets the time and inclination to do so. I
suggested the idea of recursion because I thought that it would be a simple
add-in with a little bit of consideration.
Why stop at the simple re-creation of the summary window? Why not go
further and start storing graphing information about each node? Recursion and
non-recursion is really a matter of preference. I generally prefer
non-recursive implementations, but sometimes it's just easier and faster
(coding) to do recursive implementations...
