Guy Harris wrote:
>
> > You could do a combination of 1 and 2, but split the
> > conversion/formatting into a separate set of routines.
> >
> > That way, the display/filtering code uses a standard format, but the
> > application developers can just feed it in the format that it comes from
> > their packet - or they can use a simple standardized routine for doing
> > the conversion to pass in.
> >
> > You could use the BASE_* field to overload for time format conversions.
> >
> > One possbility is also going to a field-type/field-sub-type mechanism,
> > although that would likely be messier in some aspects.
>
> Hmm. Perhaps the field type could split into field-type and
> field-subtype bitfields, so you could still have a single type value?
>
> (Or perhaps we could have the set of field types be expandable, with
> types having, say, routines to:
>
> generate a text-form display of the data, to use when
> constructing the text for the protocol tree;
>
> parse a text-form version of the data, to use when parsing
> display filters;
>
> extract the data from a packet and put it into a format for
> comparison;
>
> and then a dissector could add its own types without having to assault
> "proto.c" directly. A "type" value might then be what you get back from
> a routine that registers a type.)
I like that idea... I can think of a number of cases where I'd like to
be able to "register" a data type and a set of routines to handle
displaying that data type. In particular, with the packet-rx.c and
packet-afs.c code I'll be sending you sometime later this week (coming
along quite nicely) - there are a number of data types present that I've
wound up writing specialty routines to add a bunch of elements to the
proto_tree, whereas it would be nice to be able to just add a MY_AFS_ACL
element to the tree, and have it automatically handle the display. It
would be even better if it "data types" could comprise more than just a
single line in the proto_tree, such as registering a multi-element
bitfield that will process/display itself all in one shot.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
