Ed Warnicke wrote:
>
> Just my two sense worth, but my gut tendency is to avoid FT type bloat.
> Do you really need a new type? What does this new type accomplish
> that cannot be accomplished by the existing FT types? The more types
> there are the more work has to be done whenever new features are
> introduced that need to be type aware (like dranges).
The alternative point of view is that FT types are infrastructure
that make dissectors easier to write (they become a line of code
per field), allows novice programmers to write dissectors (and most
Ethereal contributors are people doing another job, but need a dissector
for the protocol that is troubling them in that job) and makes the user
experience consistent.
It also allows one variable change to alter the behaviour of that
FT type across all dissectors. For example, consider someone in
Australia doing a decode of stuff captured in the US. There's
currently no way to apply a consistent local time offset short
of stuffing about with the operating system.
More precise FT types also help dissector authors from falling
into traps. Ethereal currently has one type for dotted-quad IPv4
addresses. This is bad: source addresses are different from
destination addresses are different from route advertisment
addresses are different from subnet masks. At the moment Ethereal
doesn't highlight impossible multicast source addresses, doesn't
highlight a routing mask of 255.255.255.254 (/31), doesn't
highlight a destination address of 0.0.0.0, doesn't highlight
a route of 127.0.0.0/8-32.
And these are the traps for one seemingly obvious field.
Notoriously complex fields like times and intervals are not
handled well at all. And worse, they are handled inconsistently
between dissectors.
Protocols also deliberately include parts of other protocols.
So far, fields like TCP port numbers are handled through global
functions rather than being a type. This will hurt in the longer
term. For example, when filtering on TCP ports the user needs to
enter an integer, the IANA protocol name is not acceptable.
Having the TCP port as a type is a generic solution to this.
Glen
