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:[EMAIL PROTECTED] 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.
