On Saturday, March 22, 2003 Jason House wrote:
> I guess one other question is, how tied to the XML will the dissector
> itself be? Does the XML simply list a large number of values for a
> field, or do the values also indicate further action that should be
> taken? If that is true, there could possibly be a significant
> performance boost (per packet and startup) if you use a utility to
> generate the dissector from the source XML.
The dissector would be dependent on the XML parser for the definition of
certain fields. At this point, I was only planning on using XML to list
the enormous number of enumeration values. I wasn't overly concerned
with optimizing the startup; not that I want to make it slow - but it
doesn't warrant the same kind of performance scrutiny that packet
dissection should get. The XML parsing would only occur during startup.
Packet dissection would occur pretty much the way it currently does.
Not only that, but I wanted to allow non-coders to change or add to the
enumeration list (these enumeration lists are changed frequently and
often are customized at each location where this protocol is used).
Implementing the enumerations as a data file allows users to update the
protocol (at least as far as the enumerations are concerned) to their
local usage without having to modify or recompile the code.
It has occurred to me to describe the protocol in XML as well - but the
discussion of ASN.1 a year ago, and the fact that I simply don't have
the time as kept me from pursuing that line of thinking.
Jim