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).
One of the problems I face when trying to implement dranges (and extend the
existing ranges to other types) was that there where so many types to have to
implement against. This tends to lead to incomplete implementations
of features across types which leads to inconsistent user experience.
If there is a good reason to add a new type then please, by all means, do
so. But do consider the additional overhead that addition imposes on
the rest of the code base.
Ed
On Wed, 24 Jan 2001, Frank Singleton wrote:
> Gilbert Ramirez wrote:
> >
> > On Wed, Jan 24, 2001 at 02:31:38PM -0600, Frank Singleton wrote:
>
> > > I wanted to add some new FT_ types and browsed proto.[ch]
> > >
> > > Is this the only place that needs modifying, or have
> > > I missed something ?
> >
> > In the current form, a new FT type would have to be worked in
> > by modifying proto.c, dfilter.c, dfilter-scanner.l and
> > dfilter-grammar.y.
> >
> > You might want to wait on updating all those. I've been working
> > on some major changes to both the FT_* type system and the
> > display filter code. The FT_* types are modularized and moved
> > into a separate directory under epan, and the display filter
> > code is re-written to be a lot cleaner, simpler, and modifiable.
>
> Hi Gilbert,
>
> Thanks for the info.
>
> Ok, I have finally started up on this CORBA/IDL stuff,
> and was thinking about FT_CDR_xxx types for giop/iiop.
>
> Initially I was going to use packet-giop.[ch]
> as I have proposed earlier, but it would be nice
> to bolt it into the ethereal FT_xx types and
> make use of proto_tree_add_item() with the new
> types.
>
> eg:FT_CDR_LONG, as in
>
> static hf_register_info hf[] = {
> {
> &hf_giop_message_type,
> {
> "Message type", "giop.type",
> FT_CDR_LONG, BASE_DEC, NULL, 0x0, ""}
> }
> etc..
>
> Will your changes make it into ethereal anytime soon ?
> It would be nice for me. Otherwise I am forced to use
> my previous strategy of adding lots of things to packet-giop.
>
> Comments ??
>
> Cheers / Frank..
>
> --
> EUS/SV/Z Frank Singleton ASO Americas BSS
> Office : +1 972 583 3251 ECN 800 33251
> Pager : +1 800 651 1184 Mobile : +1 214 228 0874
> Amateur Radio: VK3FCS/KM5WS Email : frank.singleton@xxxxxxxxxxxx
>
> Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>