Apologies for introducing confusion when using the word "plugin". I meant
that by having this functionality in purpose-built compiled "modules" we can
avoid the expression interpretation since the arithmetic would then be
executed in native code immediately (no expression interpretation needed).
But I must say I'm more in favor of the (perhaps slower) generic analysis
display.
I should read the discussions on the taps again, but I think they are the
key to this implementation.
So the next question pops us: which types of generic "display widgets" do we
need (want to implement)?
* Table based (statistical analysis, or even per packet)
* Plot based (same remark)
Regards,
Olivier
-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Biot Olivier said:
> This discussion leads to the following proposal for enhancement: what if
> we generate a flexible way of presenting graphical analysis of protocol
> data, a thing like the filter logic already built into Ethereal? We
> could easily save those analysis displays (as we save e.g., color
> filters), and when presenting them give the window the appropriate name.
I.e, have a tap that interprets arithmetic expressions constructed using
field names, and lets you draw graphs (or show tables) based on that?
That sounds like a reasonable idea.
> This way, we could easily add new graphical analysis "filters" without
> having to recompile the code. Unless a "plugin" approach is followed
> (expression calculation must not be interpreted then).
A "plugin" approach where?
Plugin dissectors wouldn't cause problems except for expressions using
fields from plugins *if* you don't have that plugin - but, in that case,
I'd just expect Ethereal to report the same error it'd report if you used
a completely bogus field name.
Plugin taps shouldn't make a difference to that "generic" tap.